对于 Stacy、Grace 和 Zoe,他们是我最大的支持者,让我所有的努力都值得。
For Stacy, Grace, and Zoe who are my biggest supporters and make all my effort worthwhile.
并纪念我亲爱的同事兼导师卢克·巴雷特 (Luke Barrett)。卢克改变了我的生活,就像他改变了无数其他人一样。
And in memory of Luke Barrett, a dear colleague and mentor of mine. Luke made a difference in my life as he did countless others.
敏捷软件开发兴起的有益后果之一是将大的需求集拆分成更小的块的概念。这些块——故事——使开发项目的进度更加可见。当一个产品逐个故事构建时,每个故事的实现都完全集成到软件产品中,每个人都可以看到产品的成长。通过使用对用户有意义的故事,开发人员可以通过确定接下来要构建的故事来引导项目。这种更高的可见性有助于鼓励用户更多地参与——他们不再需要等待一年或更长时间才能看到开发团队在做什么。
One of the beneficial consequences of the rise of Agile software development is the notion of splitting up large sets of requirements into smaller chunks. These chunks—stories—enable much more visibility into the progress of a development project. When a product is built story-by-story, with each story’s implementation fully integrated into the software product, everyone can see the product grow. By using stories that make sense to users, developers can steer the project by determining which stories to build next. This greater visibility helps encourage greater participation from users—no longer do they have to wait a year or more to see what the development team’s been up to.
但是这种分块有一些负面影响。其中之一是很容易忘记软件系统应该做什么的大局。您最终可能会得到一堆乱七八糟的碎片,无法组成一个连贯的整体。或者您可能最终构建了一个对用户没有真正帮助的系统,因为您因迷失在细节中而错过了所需内容的本质。
But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by getting lost in the details.
故事地图是一种技术,它提供了一堆故事经常遗漏的大局。
Story mapping is a technique that provides the big picture that a pile of stories so often misses.
就是这样,真的——用一句话描述这本书。这句话带有很多价值的承诺。大图有助于与用户进行有效沟通,帮助所有相关人员避免构建不必要的功能,并为一致的用户体验提供方向。当我与 ThoughtWorks 的同事谈论他们如何开发他们的故事时,故事地图经常作为一项核心技术出现。他们通常是从 Jeff 举办的研讨会中学到这项技术的,因为他是开发这项技术并且最能传达这项技术的人。本书让更多人直接从源头上了解这项技术。
That’s it, really—the description of this book in a single sentence. And that sentence carries with it the promise of a lot of value. A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. When I talk to my colleagues at ThoughtWorks about what they do to develop their stories, story mapping regularly comes up as a core technique. Often they’ve learned that technique from workshops run by Jeff, because he’s the one who developed the technique and can best communicate it. This book allows more people to understand this technique directly from its source.
但这不仅仅是为名片或在线个人资料上有“业务分析师”字样的人准备的书。在采用敏捷方法的十年中,对我来说最大的失望也许是许多程序员将故事视为分析师与他们的单向交流的方式。从一开始,故事就应该引发对话. 如果你真的想想出有效的软件来支持一项活动,那么你需要将那些构建软件的人视为其功能的重要思想来源,因为程序员最了解软件的功能。程序员需要了解他们的用户正在努力实现什么,并且应该协作构建捕捉这些用户需求的故事。了解故事映射的程序员可以更好地了解更广泛的用户上下文,并可以参与构建软件——从而获得更好的工作。
But this isn’t just a book for people who have something like “business analyst” on their business card or online profile. Perhaps the biggest disappointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.
当 Kent Beck(提出“故事”概念的人)提出他关于软件开发的想法时,他称沟通是高效团队的关键价值。故事是开发人员与使用他们作品的人之间进行交流的基石。故事地图组织和构建这些构建块,从而增强这种沟通过程——这是软件开发本身最关键的部分。
When Kent Beck (who originated the notion of a “story”) developed his ideas on software development, he called out communication as a key value of effective teams. Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of software development itself.
在玛丽·雪莱 (Mary Shelley) 著名的科幻小说《科学怪人》( Frankenstein ) 中,疯狂的弗兰肯斯坦博士用不同的死人碎片制造了一个生物,并用当时的新技术使这个生物复活。当然,我们知道这实际上是不可能的。你不能通过将随机的身体部位缝合在一起来创造生命。
In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts.
然而,这正是软件开发人员一直试图做的事情。他们为软件添加好的功能,一次一个,然后想知道为什么很少有用户喜欢他们的产品。难题的核心是开发人员将他们的构造方法用作设计工具,但两者不可互换。
Yet this is what software developers attempt to do all the time. They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that developers are using their construction method as a design tool, but the two are not interchangeable.
程序员一次构建软件一个功能是完全合理的。这是一个非常好的策略,经过多年的验证。多年来还被证明的是,当用作设计数字产品的行为和范围的方法时,一次一个功能会产生程序的弗兰肯斯坦怪物。
It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.
虽然它们密切相关,但设计软件行为的实践和构建该软件的实践截然不同,并且通常由具有不同技能的不同人员执行。交互设计师花在观察用户和映射行为模式上的许多时间会让大多数程序员抓狂。相反,对大多数设计师来说,为算法苦苦挣扎的时间太孤独了。
While they are intimately related, the practice of designing software behavior and the practice of building that software are distinctly different, and are typically performed by different people with different skill sets. The many hours that interaction designers spend observing users and mapping behavior patterns would drive most programmers batty. Conversely, the hours of sweating over algorithms are too solitary for most designers.
但是,当设计和开发这两种实践方式协作时,这项工作就会变得充满活力,并有可能创造出一种活生生的、会呼吸的产品。团队合作为怪物注入了生命,让人们爱上了它。
But when the two strains of practice—design and development—collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.
虽然协作的想法既不新鲜也不是特别有见地,但实际上很难有效地做到这一点。开发人员的工作方式——他们的节奏、语言和节奏——与交互设计师的工作方式截然不同。
While the idea of collaboration is neither new nor particularly insightful, it is actually very difficult to do effectively. The way that developers work—their pace, language, and rhythm—is quite different from that of interaction designers.
这两个领域的从业者都很强,有能力,而且内部纪律严明,但他们有一个共同的弱点。用编程术语表达设计问题真的很难,用设计术语表达开发问题同样困难。这两个姊妹学科缺乏共同语言。而这两个学科之间的交汇点正是杰夫·巴顿 (Jeff Patton) 居住的地方。
Practitioners in each of the two fields are strong, capable, and internally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction between the two disciplines is precisely where Jeff Patton lives.
Jeff 的故事映射方法对开发人员很有意义,对设计师也同样有意义。故事地图是我们数字时代的罗塞塔石碑。
Jeff’s method of story mapping makes sense to developers, and it makes equal sense to designers. Story mapping is the Rosetta Stone for our digital age.
尽管有相反的说法,敏捷开发并不是一个非常有用的设计工具。这是一种设计友好的开发思维方式,这是一件非常好的事情,但它本身不会让您获得用户喜爱的产品。另一方面,我们已经多次看到好的设计、有据可查的文档提供给开发人员(无论是否敏捷),他们设法在实施过程中扼杀了设计的本质。
Despite protestations to the contrary, Agile development is not a very useful design tool. It is a way of thinking about development that is design-friendly, which is a very good thing, but by itself it won’t get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation.
巴顿的故事映射方法是跨越这个鸿沟的桥梁。交互设计就是要找到用户的真相并将其作为叙述来讲述。软件开发就是将这些叙述分解成微小的功能块,然后实施和集成它们。在这个复杂的过程中,叙事的本质很容易就溜走了。是的,功能实现了,但是病人死在了手术台上。
Patton’s story mapping approach is the bridge over this chasm. Interaction design is all about finding the user’s truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. It’s so ridiculously easy for the essence of the narrative to slip away during this complex process. Yes, the functions are implemented, but the patient dies on the operating room table.
通过绘制用户故事,设计保留了其叙事结构,但仍可以解构以有效实施。设计师的故事是用户故事的形式化版本,在整个开发过程中保持不变。
By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of the user’s story, remains intact throughout the development.
传统的企业界已经证明,两三百人的团队几乎不可能打造出人们喜爱的产品。与此同时,创业社区已经证明,四五个人的团队可以打造出人们喜爱的小产品,但即使是这些小产品最终也会变大并失去火花。我们面临的挑战是创建人们喜爱的大型软件。大型软件为大量受众提供复杂的、商业上可行的工作。要让这样的软件既有趣又易于学习是非常困难的。
The conventional corporate world has proven that it is nearly impossible for a team of two or three hundred people to build a product that people love. Meanwhile the startup community has proven that a team of four or five people can build small products that people love, but even these little products eventually grow big and lose their spark. The challenge we face is creating big software that people love. Big software serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn.
我们要构建不是弗兰肯斯坦怪物的大型软件的唯一方法是学习如何整合软件设计和开发的学科。没有人比 Jeff Patton 更了解如何做到这一点。
The only way we are going to build big software that is not a Frankenstein monster is by learning how to integrate the disciplines of software design and development. Nobody knows how to do that better than Jeff Patton.
我非常幸运能够与世界上许多最优秀的技术产品团队一起工作。人们每天都在创造您使用和喜爱的产品。真正改变世界的团队。
I’ve had the extremely good fortune to be able to work with many of the very best technology product teams in the world. People creating the products you use and love every day. Teams that are literally changing the world.
我也受邀尝试帮助表现不佳的公司。初创公司竞相在资金用完之前获得一些牵引力。大公司努力复制他们的早期创新。团队未能持续为其业务增加价值。领导者对从想法到现实需要多长时间感到沮丧。工程师们对他们的产品负责人感到恼火。
I’ve also been brought in to try to help companies that are not doing so well. Startups racing to get some traction before the money runs out. Larger companies struggling to replicate their early innovation. Teams failing to continuously add value to their business. Leaders frustrated with how long it takes to go from idea to reality. Engineers exasperated with their product owners.
我所了解到的是,最好的产品公司创造技术产品的方式与其他公司之间存在着深刻的差异。我不是说细微差别。我指的是从领导者的行为方式到团队授权水平的方方面面;团队合作的方式;组织如何考虑资金、人员配备和生产产品;对文化;了解产品、设计和工程如何协作,为他们的客户发现有效的解决方案。
What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. I mean everything from how leaders behave to the level of empowerment of teams; to the way teams work together; to how the organization thinks about funding, staffing, and producing products; to the culture; to how product, design, and engineering collaborate to discover effective solutions for their customers.
这本书的标题是User Story Mapping,但您很快就会发现它所涉及的远不止这种强大而简单的技术。这本书的核心是团队如何协作、沟通,并最终想出好东西来构建。
This book is titled User Story Mapping, but you’ll soon see it is about much more than this powerful yet simple technique. This book gets to the heart about how teams collaborate, communicate, and ultimately come up with good stuff to build.
你们中的许多人从未有机会近距离了解强大的产品团队是如何运作的。您可能知道的只是您在公司或以前工作过的地方看到的情况。所以我想在这里做的是试着让你了解最好的球队与其他球队有多么不同。
Many of you have never had a chance to see up close how a strong product team operates. All you may know is what you’ve seen at your company or where you’ve worked before. So what I’d like to do here is to try to give you a flavor of just how different the best teams are from the rest.
感谢 Ben Horowitz 的《好产品经理,坏产品经理》,以下是强产品团队和弱产品团队之间的一些重要区别:
With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differences between strong product teams and weak teams:
优秀的团队拥有令人信服的产品愿景,他们以传教士般的热情追求这一愿景。糟糕的团队是雇佣军。
优秀的团队从他们的记分卡 KPI、观察客户的挣扎、分析客户使用他们的产品产生的数据以及不断寻求应用新技术来解决实际问题中获得灵感和产品创意。糟糕的团队从销售和客户那里收集需求。
优秀的团队了解他们的主要利益相关者是谁,他们了解这些利益相关者所处的制约因素,并且他们致力于发明不仅对用户和客户有效,而且在业务约束范围内有效的解决方案。糟糕的团队从利益相关者那里收集需求。
优秀的团队精通多种技术,可以快速尝试产品创意,以确定哪些产品真正值得打造。糟糕的团队召开会议来生成优先路线图。
优秀的团队喜欢与全公司聪明的思想领袖进行头脑风暴讨论。当团队外的人胆敢建议他们做某事时,糟糕的团队会被冒犯。
优秀的团队让产品、设计和工程部门并肩工作,并接受功能、用户体验和支持技术之间的取舍。不好的团队坐在各自的职能区域,要求其他人以文件和安排会议的形式提出对他们服务的要求。
优秀的团队不断尝试新想法以进行创新,但这样做的方式可以保护收入和品牌。糟糕的团队仍在等待运行测试的许可。
优秀的团队坚持认为他们拥有创造成功产品所必需的技能组合,例如强大的交互设计。糟糕的团队甚至不知道交互设计师是什么。
优秀的团队确保他们的工程师每天都有时间尝试发现原型,这样他们就可以就如何让产品变得更好发表自己的想法。糟糕的团队在冲刺计划期间向工程师展示原型,以便他们进行估算。
优秀的团队每周都会与最终用户和客户直接接触,以更好地了解他们的客户,并了解客户对他们最新想法的反应。糟糕的团队认为他们是客户。
优秀的团队知道,他们最喜欢的许多想法最终不会为客户服务,即使是那些可能需要多次迭代才能达到他们提供预期结果的点。糟糕的团队只会按照路线图构建内容,并对会议日期和确保质量感到满意。
优秀的团队了解对速度的需求以及快速迭代是创新的关键,并且他们了解这种速度来自正确的技术而不是强迫劳动。糟糕的团队抱怨他们工作缓慢,因为他们的同事工作不够努力。
优秀的团队在评估请求并确保他们拥有切实可行的解决方案后,会做出高度诚信的承诺,这些解决方案将真正为客户和企业服务。糟糕的团队抱怨自己是一家以销售为导向的公司。
优秀的团队会检测他们的工作,以便他们可以立即了解他们的产品是如何被使用的,并根据数据做出调整。糟糕的团队认为分析和报告是“可有可无的”。
优秀的团队会持续集成和发布,因为他们知道源源不断的较小版本会为他们的客户提供更稳定的解决方案。糟糕的团队在痛苦的集成阶段结束时手动测试,然后立即发布所有内容。
优秀的团队会关注他们的参考客户。糟糕的团队对竞争对手很着迷。
优秀的团队在对业务 KPI 产生重大影响时庆祝。糟糕的团队在他们终于发布一些东西时庆祝。
Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.
Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.
Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.
Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.
Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings.
Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test.
Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are.
Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.
Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.
Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.
Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.
Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company.
Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”
Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.
Good teams obsess over their reference customers. Bad teams obsess over competitors.
Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when they finally release something.
我知道您可能想知道这一切与故事地图有什么关系。我想你会感到惊讶。这正是我喜欢故事地图的原因。
I realize you might be wondering what all this has to do with story maps. I think you’ll be surprised. And that’s precisely why I am a fan of story maps.
我只见过少数敏捷专家,我认为他们有资格真正帮助一个认真的产品团队将其游戏提升到公司需要和应得的水平。杰夫巴顿就是其中之一。我观察到他在发现产品的过程中与团队一起在战壕中亲身实践。我把他介绍给公司,因为他很有效率。团队喜欢他,因为他知识渊博但又谦虚。
I have met only a few Agile experts whom I consider qualified to actually help a serious product team raise its game to the level its company needs and deserves. Jeff Patton is one of them. I have observed him working hands on in the trenches with teams in the midst of product discovery. I introduce him into companies because he is effective. Teams love him because he is knowledgeable yet humble.
产品经理收集并记录需求,设计师争先恐后地在产品上涂点口红,工程师躲在地下室里编码的日子,对于最好的团队来说早已一去不复返了。他们也该离开您的团队了。
The days of product managers gathering up and documenting requirements, designers scrambling just to put some lipstick on the product, and engineers sheltered in the basement, coding, are long gone for the best teams. And it’s time they are gone for your team, too.
生活在其中,游泳在其中,欢笑在其中,爱在其中/去除轮廓板上令人尴尬的污渍,没错/它招待来访的亲戚,它把三明治变成宴会。
— Tom Waits,“站起来”
Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.
— Tom Waits, “Step Right Up”
这本书应该是一件小事……一本小册子,真的。
This book was supposed to be a small thing…a pamphlet, really.
我开始写一个简单的实践,我称之为故事映射。我和许多其他人一起构建简单的地图,以帮助我们与他人合作并想象使用产品的体验。
I set out to write about a simple practice I called story mapping. I, and lots of other folks, build simple maps to help us work together with others and to imagine the experience of using a product.
故事地图让我们专注于用户和他们的体验,结果是更好的对话,最终是更好的产品。
Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.
构建地图非常简单。我将与其他人一起讲述一个产品的故事,将用户在故事中采取的每一个重大步骤以从左到右的顺序写在便签上。然后,我们将回过头来讨论每个步骤的细节,并将这些细节写在便利贴上,并垂直放置在每个步骤下方。结果是一个简单的网格状结构,从左到右讲述一个故事,并从上到下分解成细节。它既有趣又快速。这些细节使我们的敏捷开发项目的故事积压得更好。
Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.
写一本关于这个的书有多复杂?
How complicated could writing a book about this be?
但事实证明,即使是简单的事情也可以非常复杂。写下为什么要构建故事地图、构建故事地图时会发生什么以及使用故事地图的所有不同方式花了我很多页。这个简单的练习比我想象的要多。
But it turns out that even the simple things can be pretty sophisticated. And writing about why you would want to build a story map, what’s going on when you build one, and all the different ways you can use one took me a lot of pages. There was more to this simple practice than I thought.
如果您使用的是敏捷开发流程,您可能会用用户故事填充积压工作。我原以为,既然讲故事是一种常见的做法,那么在这本书中写这些故事对我来说是浪费时间。但是我错了。自肯特·贝克 (Kent Beck) 首次描述故事以来的十五年里,它们比以往任何时候都更受欢迎,也更容易被误解和误用。那样令我伤心。而且,更重要的是,它扼杀了我们从故事地图中获得的所有好处。
If you’re using an Agile development process, you’re likely filling backlogs with user stories. I’d assumed that since stories were such a common practice, it’d be a waste of time for me to write about them in this book. But I was wrong. In the decade and a half since stories were first described by Kent Beck, they’re more popular—and more misunderstood and misused—than ever before. That makes me sad. And, what’s more, it kills all the benefit we get from story mapping.
因此,在本书中,我想纠正尽可能多的关于故事及其在敏捷和精益软件开发中的使用方式的重大误解。这就是为什么,用 Tom Waits 的话来说,我把这个“三明治变成了宴会”。
So, in this book, I would like to correct as many big misconceptions as I can about stories and the way they’re used in Agile and Lean software development. That’s why, in the words of Tom Waits, I’ve turned this “sandwich into a banquet.”
我喜欢做东西。激励我的是我从创建一个软件并看到人们使用它并从中受益所获得的快乐。我是一个不情愿的方法论者。我发现我需要学习过程和实践如何工作才能更好地掌握它们。在从事软件开发 20 多年之后,我现在才开始学习如何教授我所学的知识。我知道我所教的是一个移动的目标。我的理解每周都在变化。如何最好地解释它的变化几乎一样快。所有这些都让我多年来没有写一本书。
I like making things. What motivates me is the joy I get from creating a piece of software and seeing people use it and benefit from it. I’m a reluctant methodologist. I found I needed to learn how process and practice work to get better at them. I’m only now learning after 20-plus years in software development how to teach what I’ve learned. And I know that what I teach is a moving target. What I understand changes every week. How best to explain it changes almost as fast. All that’s kept me from writing a book for years.
但现在是时候了。
But it’s time.
故事和故事地图是个好主意。他们让很多人受益。他们让自己的生活更美好,他们打造的产品也更美好。但是,虽然有些人的生活越来越好,但与以往任何时候相比,越来越多的人都在为故事而苦苦挣扎。我想帮助阻止它。
Stories and story maps are such a good idea. They’ve benefited so many people. They’ve made their lives better, and the products they build better. But while some people’s lives are getting better, there are more people struggling with stories than ever before. I want to help stop that.
这本书是我可以提供帮助的东西。而且,即使它改善了少数人的工作生活,我也会庆祝。
This book is something I can make to help. And, if it improves the work lives of even a few, I’ll celebrate.
由于如此多的组织采用了敏捷和精益流程,以及随之而来的故事,您可能会因对故事的误解而陷入一个或多个陷阱。像这样的陷阱:
Because so many organizations have adopted Agile and Lean processes, and stories along with them, you may fall into one or more of the traps caused by misconceptions about stories. Traps like these:
如果您掉进了这些陷阱中的任何一个,那么我会首先尝试消除导致这些陷阱的误解。您将学习如何从大局着眼,如何从大局(和小局)进行计划和估算,以及如何就用户想要完成的事情以及软件的好坏进行富有成效的对话需要帮助他们。
If you’ve fallen into any of those traps, then I’ll try to wipe away the misconceptions that lead to those traps in the first place. You’ll learn how to think of the big picture, how to plan and estimate in the large (and in the small), and how to have productive conversations about what users are trying to accomplish, as well as what a good piece of software needs to do to help them.
你应该,当然。特别是如果你买了它。一方面,我认为您进行了明智的投资。如果你只是借用它,你应该现在就订购自己的,并在新的到达你家时归还你借用的那个。
You should, of course. Especially if you bought it. I, for one, think you’ve made a wise investment. If you’re just borrowing it, you should order your own now, and return the one you’ve borrowed when the new one arrives at your door.
然而,阅读本书为担任特定角色的从业者提供了特定的原因和好处:
However, reading this book offers specific reasons and benefits for practitioners in specific roles:
我希望您认同我刚才描述的一个或多个群体。如果您不这样做,请将这本书送给这样做的人。
I’m hoping you identify with one or more of the groups I just described. If you don’t, give this book to someone who does.
如果你这样做,让我们开始吧。
If you do, let’s get started.
我怀疑这不是您读过的唯一一本关于软件开发的书,因此您应该不会感到惊讶。
I suspect this isn’t the only book on software development you’ve ever read, so nothing should surprise you.
使用它们来找到您的方式或跳过您现在不感兴趣的内容。
Use them to find your way or skip over stuff you’re not interested in right now.
关键点看起来像这样。想象一下,我说这些比其他所有文字都大声。
Key points look like this. Imagine me saying these a bit louder than all the other text.
如果您正在略读,请阅读要点。如果您喜欢它们,或者它们不是很明显,请阅读它们前后的文字。这应该让他们清楚。
If you’re skimming, read the key points. If you like them, or they’re not dead obvious, read the text before and after them. That should make them clear.
这本书被组织成特定的部分。您可以一次阅读一个部分,或者使用这些部分来帮助您找到应对当前特定挑战的想法。
The book is organized into specific sections. You could read it a section at a time, or use the sections to help you find ideas for a specific challenge you have right now.
不久前我买了一台很酷的新型彩色激光打印机。我打开盒子,打印机上面放着一本小册子,上面用红色大字写着“请先阅读本文”。我想知道,“我真的应该先读这个吗?” 因为我通常不照我说的做。但我很高兴我这么做了,因为打印机内部的各个地方都有很多塑料防护装置,以保证它在运输过程中的安全,如果我在取下它们之前插上电源,我可能会损坏打印机。
I bought a cool new color laser printer a while back. I opened the box, and sitting on top of the printer was a pamphlet with “Read This First” in big red letters on it. I wondered, “Should I really read this first?” because I usually don’t do as I’m told. But I’m glad I did, because there were lots of plastic guards in various places inside the printer to keep it safe during shipping, and if I’d plugged it in before removing them, I might have damaged the printer.
这个故事听起来像是一个切线,但事实并非如此。
This story might sound like a tangent, but it’s not.
本书包含“首先阅读此书”一章,因为我将在本书的其余部分中使用两个关键概念和相关词汇。我希望您在开始之前在脑海中有这些概念。如果您在理解它们之前就开始使用故事地图,我无法保证您的安全。
This book contains a “Read This First” chapter because there are two critical concepts and associated vocabulary that I’ll use throughout the rest of the book. I’d like you to have those concepts in your head before you get started. If you start to story map before you understand them, I can’t guarantee your safety.
第1章到第4章将为您提供故事地图的高级视图。如果您已经使用故事一段时间并且之前玩过故事地图,那么本节应该足以让您立即开始。
Chapters 1–4 will give you a high-level view of story mapping. If you’ve been using stories for a while and played with a story map before, this section should give you enough to get going right away.
第 5 章提供了一个极好的练习,可帮助您学习用于创建出色故事地图的关键概念。在你的办公室与一群人一起尝试,每个参与的人都会得到它。我向您保证,他们为您的产品创建的地图之后会更好。
Chapter 5 gives you a nifty exercise to help you learn the key concepts used to create a great story map. Try it out with a group in your office, and everyone who participates will get it. And I promise you the maps they create for your products will come out better afterward.
第6章到第12章讲述了故事背后的故事、它们的真正作用以及如何在敏捷和精益项目中充分利用它们。内部故事地图包含许多可用于推动日常开发的小故事。即使您是一名敏捷老手,我也保证您会学到一些您还不知道的故事。而且,如果您是故事的新手,您将学到足够多的知识,足以让办公室里的敏捷专家大吃一惊。
Chapters 6–12 tell the story behind stories, how they really work, and how to make good use of them in Agile and Lean projects. Inside story maps are lots of little stories you can use to drive day-to-day development. Even if you’re an Agile veteran, I promise you’ll learn something about stories you didn’t already know. And, if you’re new to stories, you’ll learn enough to surprise the Agile know-it-alls at your office.
第13至15章深入探讨了故事的生命周期。我将讨论帮助您使用故事和故事地图的具体实践,从重大机会开始,然后通过发现工作确定充满故事的积压工作,这些故事描述了一个可行的产品。您将了解故事地图和许多其他实践如何在整个过程中为您提供帮助。
Chapters 13–15 dive deep into the lifecycle of a story. I’ll discuss specific practices that help you use stories and story maps, starting with big opportunities and moving through the discovery work to identify a backlog full of stories that describe a viable product. You’ll learn how story maps and lots of other practices can help you every step of the way.
第16章到第18章深入探讨了在战术上、逐个迭代或逐个冲刺地使用故事。您将学习如何准备故事、在构建故事时集中注意力、真正完成它们,以及如何真正从您转换为工作软件的每个故事中学习。
Chapters 16–18 dive deeper into using stories tactically, iteration-by-iteration or sprint-by-sprint. You’ll learn how to get stories ready, to pay attention while they’re built, to really get them done, and to really learn from each story you convert to working software.
我发现很多软件开发书籍的最后几章都是多余的垃圾。我通常可以忽略它们。不幸的是,我没有写任何这些章节。你需要阅读整本书。我对您唯一的安慰是,您将从每一章中获得一些有用的块,您可以立即投入使用。
I find that the last few chapters of many software development books are the extra junk. I can usually ignore them. Unfortunately, I didn’t write any of those chapters. You’ll need to read the whole book. My only consolation to you is that you’ll get some useful nuggets out of every chapter that you can put to work right away.
让我们开始吧。
Let’s get to it.
Safari Books Online是一个按需点播的数字图书馆,以书籍和视频形式提供来自世界技术和商业领域领先作者的专家内容。
Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.
技术专业人士、软件开发人员、网页设计师以及商业和创意专业人士使用 Safari Books Online 作为他们研究、解决问题、学习和认证培训的主要资源。
Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.
Safari Books Online为企业、政府、教育和个人提供一系列计划和定价。
Safari Books Online offers a range of plans and pricing for enterprise, government, education, and individuals.
会员可以访问来自 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 等数百家。有关 Safari Books Online 的更多信息,请在线访问我们。
Members have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and hundreds more. For more information about Safari Books Online, please visit us online.
请将有关本书的评论和问题发送给出版商:
Please address comments and questions concerning this book to the publisher:
| 奥莱利媒体公司 |
| 1005 Gravenstein 公路北 |
| 塞瓦斯托波尔, CA 95472 |
| 800-998-9938(美国或加拿大) |
| 707-829-0515(国际或本地) |
| 707-829-0104(传真) |
我们有本书的网页,其中列出了勘误表、示例和任何其他信息。您可以访问此页面http://bit.ly/user-story-mapping。
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/user-story-mapping.
要对本书发表评论或提出技术问题,请发送电子邮件至bookquestions@oreilly.com。
To comment or ask technical questions about this book, send email to bookquestions@oreilly.com.
有关我们的书籍、课程、会议和新闻的更多信息,请访问我们的网站http://www.oreilly.com。
For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.
在 Facebook 上找到我们:http: //facebook.com/oreilly
Find us on Facebook: http://facebook.com/oreilly
在 Twitter 上关注我们:http: //twitter.com/oreillymedia
Follow us on Twitter: http://twitter.com/oreillymedia
在 YouTube 上观看我们:http ://www.youtube.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia
这本书没有简介。
This book has no introduction.
是的,你看的没错。现在,您可能会立即问自己,“为什么 Jeff 的书没有介绍?他忘记写了吗?这么多年了,他是不是开始滑倒了?!狗吃了吗?”
Yes, you read that right. Now, you might immediately ask yourself, “Why doesn’t Jeff’s book have an introduction? Did he forget to write it? Is he beginning to slip after all these years?! Did the dog eat it?”
不,我没忘记给这本书写个介绍。而且,不,我没有开始滑倒。至少我不认为我是。我的狗没有吃它(虽然我女儿的豚鼠看起来很可疑)。只是我长期以来一直认为作者花了太多时间来说服我应该读他们的书,而引言中有大量的说服力。大多数书籍的内容通常要到第 3 章才开始。而且我敢肯定,这样做的不仅是我,而且我通常会跳过介绍。
No, I didn’t forget to write an introduction to this book. And, no, I’m not beginning to slip. At least I don’t think I am. And my dog didn’t eat it (although my daughter’s guinea pig looks suspicious). It’s just that I’ve long believed that authors spend too much time convincing me I should read their book, and a great deal of that convincing lives in the introduction. The meat of most books usually doesn’t start until Chapter 3. And I’m sure it’s not only me who does this, but I usually skip the introduction.
这本书实际上是从这里开始的。
This book actually starts here.
你不能跳过这个,因为它确实是最重要的部分。事实上,如果你能从这本书中得到两点,我会很高兴。这两点就在本章的此处:
And you’re not allowed to skip this because it really is the most important part. In fact, if you only get two points from this book, I’ll be happy. And those two points are right here in this chapter:
让我解释。
Let me explain.
我相信你还记得你小时候玩过这种奇怪的“电话游戏”,你在这个游戏中对某人耳语,对方又对其他人耳语,如此反复,直到最后一个人说出完全乱码的信息每个人都笑了。今天,我的家人仍然在家里和我的孩子围坐在餐桌旁玩这个游戏。家长注意:这是一个很好的活动,可以让孩子们厌倦成人晚餐的谈话。
I’m sure you remember when you were a kid and you played this weird “telephone game” where you whispered something to somebody, who whispered it to someone else, and so on around the group, until the last person reveals the totally garbled message and everyone laughs. Today, my family still plays this game at home with my kids around the dinner table. Note to parents: this is a good activity to occupy kids bored with adult dinner conversation.
在成年人的世界里,我们继续着这个游戏——只是我们不再窃窃私语。我们编写冗长的文档并创建看起来很正式的演示文稿,然后将其交给某个人,而这个人会从中得到与我们预期完全不同的东西。然后那个人使用该文档创建更多文档以提供给不同的人。然而,与我们小时候玩的那个游戏不同,我们并没有在最后都笑。
In the grown-up world, we’ve continued this game—only we don’t whisper to each other. We write lengthy documents and create official-looking presentations that we hand off to someone, who proceeds to get something completely different out of it than we intended. And that person uses that document to create more documents to give to different people. However, unlike that game we played as kids, we don’t all laugh at the end.
当人们阅读书面说明时,他们会做出不同的解释。如果您觉得这有点难以置信(毕竟是书面形式!),那么让我向您展示一些说明错误非常非常严重的示例。
When people read written instructions, they interpret them differently. If you find that a little hard to believe (it’s in writing, after all!), then let me show you a few examples of instructions gone very, very wrong.
这是 Jen Yates 的书Cake Wrecks(Andrews McMeel Publishing)的封面。(感谢 Jen 和 John Yates 提供这些。)这本书疯狂地从她那里冒出来娱乐网站cakewrecks.com。如果您没有至少一个小时可以浪费,请不要去那里。该网站展示了装饰奇特的蛋糕的照片,这些照片无法解释——但尽管如此,珍还是解释了它们。现在,网站和书中反复出现的主题之一是对需求的误解。但她当然不会将它们称为要求,因为这是一个书呆子般的词。她称它们为文字,因为读者阅读并逐字解释所写的内容。看着这些照片,我可以想象有人倾听顾客的声音,写下他想要的东西,然后将其交给装饰蛋糕的其他人。
This is the cover of Jen Yates’s book Cake Wrecks (Andrews McMeel Publishing). (Thanks to Jen and John Yates for supplying these.) The book sprang from her wildly entertaining website, cakewrecks.com. Please don’t go there if you don’t have at least an hour to waste. The site shows photos of oddly decorated cakes that defy explanation—but Jen explains them in spite of that. Now, one of the recurring themes in both the site and the book is misinterpreted requirements. But of course she doesn’t refer to them as requirements because it’s such a nerdy word. She calls them literals because the reader read and literally interpreted what was written. Looking at the photos, I can imagine someone listening to a customer and writing down what he wants, then handing that to someone else who’ll decorate a cake.
顾客:您好,我想订一个蛋糕。
雇员:当然可以,您想要在上面写什么?
顾客:你能用紫色写“再见,Alicia”吗?
员工:当然。
顾客:然后在它周围放上星星?
员工:没问题。我已经写好了,马上就交给我的蛋糕装饰师。我们会在早上为您准备好。
Customer: Hello, I’d like to order a cake.
Employee: Sure, what would you like written on it?
Customer: Could you write “So long, Alicia” in purple?
Employee: Sure.
Customer: And put stars around it?
Employee: No problem. I’ve written this up, and will hand it to my cake decorator right away. We’ll have it for you in the morning.
这是结果:
This is the result:
Here’s another. In software development, we call these nonfunctional requirements:
这些都是有趣的例子,我们可以为在蛋糕上浪费 20 美元而发笑。但有时风险远不止于此。
These are funny examples, and we can laugh about wasting twenty bucks on a cake. But sometimes the stakes are much greater than that.
你可能听说过关于1999 年价值 1.25 亿美元的 NASA 火星气候轨道器坠毁。[ 1 ]好吧,也许你还没有。但这是妙语。如果有任何项目在需求和书面文档中引起了人们的注意,那么它就是 NASA 项目。然而,尽管所有文件柜都装满了要求和文件,但轨道飞行器还是坠毁了,因为虽然 NASA 使用公制进行测量,但洛克希德马丁公司工程团队的成员使用旧的英制测量系统为车辆的推进器开发导航命令。虽然没有人确切知道轨道飞行器最终去了哪里,但有些人认为它已经找到了它在火星以外某处绕太阳运行的快乐位置。
You’ve probably heard the story about the 1999 crash of a $125 million NASA Mars Climate Orbiter.[1] OK, maybe you haven’t. But here’s the punch line. If any project is sunk up to its eyeballs in requirements and written documentation, it’s a NASA project. However, despite all the filing cabinets full of requirements and documentation, the orbiter crashed because while NASA used the metric system for its measurements, members of the Lockheed Martin engineering team used the old imperial measurement system to develop navigation commands for the vehicle’s thrusters. While no one knows exactly where the orbiter ended up, some think it has found its happy place orbiting the sun somewhere past Mars.
具有讽刺意味的是,我们将内容写成书面形式以更清楚地沟通并避免误解的风险。但是,很多时候,情况恰恰相反。
Ironically, we put stuff in writing to communicate more clearly and to avoid risk of misunderstanding. But, way too often, the opposite is true.
共享文档不是共享理解。
Shared documents aren’t shared understanding.
停下来一分钟,把它写下来。把它写在便利贴上,然后放在口袋里。考虑把它纹在身上的某个地方,这样当你早上准备上班时就可以看到它。当你阅读它时,它会帮助你记住我现在给你讲的故事。
Stop for a minute and write that down. Write it on a sticky note and put it in your pocket. Consider getting it tattooed somewhere on your body so you can see it when you’re getting ready for work in the morning. When you read it, it’ll help you remember the stories I’m telling you now.
共享理解是指我们都了解对方的想法及其原因。显然,几个蛋糕装饰师和给他们书面指示的人之间没有共同的理解。而且,在 NASA,某个重要人物没有与其他从事制导系统工作的人分享理解。我敢肯定,如果您参与软件开发已有一段时间,您不必回想起过去的情况,两个人认为他们就想要添加到软件中的功能达成一致。软件,但后来发现人们想象的方式与其他人截然不同。
Shared understanding is when we both understand what the other person is imagining and why. Obviously, there wasn’t shared understanding between several cake decorators and the people who gave them instructions in writing. And, at NASA, someone important didn’t share understanding with others working on the guidance system. I’m sure if you’ve been involved in software development for a while, you don’t have to reach back far in your memory to recall a situation where two people believed they were in agreement on a feature they wanted to add to the software, but later found out that the way one imagined it was wildly different from the other.
我的一位前同事 Luke Barrett 首先画了这幅漫画来描述这个问题。我问他第一次在哪里看到它,但他不记得了。所以外面的人没有得到他或她应得的荣誉。多年来,我看到卢克在 PowerPoint 幻灯片中逐步浏览这四个框架,而我却随意地认为它们很有趣但很明显。显然我的脑袋很厚。我花了很多年才明白这部卡通片是如何说明在软件开发中使用故事的最重要的事情。
A former coworker of mine, Luke Barrett, first drew this cartoon to describe this problem. I asked him where he first saw it, but he didn’t remember. So someone out there isn’t getting the credit he or she deserves. For years I saw Luke step through these four frames as slides in a PowerPoint deck while I casually dismissed them as interesting but obvious. Apparently I’ve got a thick head. It’s taken me many years to understand how this cartoon illustrates the most important thing about using stories in software development.
我的想法是,如果我在脑海中有一个想法并以书面形式描述它,那么当您阅读该文档时,您很可能会想到一些不同的东西。我们甚至可以问每个人,“你们都同意那里写的吗?” 我们可能都会说,“是的!是的,我们有。”
The idea is that if I have an idea in my head and I describe it in writing, when you read that document, you might quite possibly imagine something different. We could even ask everyone, “Do you all agree with what’s written there?” and we might all say, “Yes! Yes, we do.”
但是,如果我们聚在一起谈谈,你可以告诉我你的想法,我可以提出问题。如果我们可以通过画图或使用索引卡或便利贴组织我们的想法来外化我们的想法,那么谈话会进行得更好。如果我们给彼此时间用文字和图片解释我们的想法,我们就会建立共同的理解。然而,正是在这一点上,我们意识到我们对事物的理解各不相同。太糟糕了。但至少现在我们知道了。
However, if we get together and talk, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes. If we give each other time to explain our thoughts with words and pictures, we build shared understanding. It’s at this point, though, that we realize that we all understood things differently. That sucks. But at least now we know.
不是一个人的对错,而是我们看到的不同的重要方面。通过组合和提炼我们不同的想法,我们最终达成了一个包含我们所有最佳想法的共同理解。这就是为什么将我们的想法外化如此重要。我们可以重新绘制草图或四处移动便利贴,最酷的是我们真的在四处移动想法。我们真正在做的是发展我们的共同理解。光靠文字就太难了。
It’s not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas. That’s why externalizing our ideas is so important. We can redraw sketches or move sticky notes around, and the cool thing is that we’re really moving ideas around. What we’re really doing is evolving our shared understanding. That’s super-hard with just words alone.
当我们离开这个对话时,我们可能仍然会提到相同的功能或增强功能,只是现在我们实际上指的是同一件事。我们感到一致并充满信心,我们正在共同前进。这就是我们要达到的质量。而且,可悲的是,它是无形的。您看不到或摸不到“共同理解”,但可以感觉到。
When we leave this conversation, we may still name the same feature or enhancement, it’s just that now we actually mean the same thing. We feel aligned and confident we’re moving forward together. That’s the quality we’re managing to. And, sadly, it’s intangible. You can’t see or touch “shared understanding,” but you can feel it.
有很多人相信有一些理想的记录方式——当人们阅读文档并得出不同的理解时,要么是读者的错,要么是文档作者的错。事实上,两者都不是。
There are a great number of people who believe that there’s some ideal way to document—that, when people read documents and come away with different understandings, it’s either the reader’s fault or the document writer’s. In reality, it’s neither.
答案就是阻止它。
The answer is just to stop it.
停止尝试编写完美的文档。
Stop trying to write the perfect document.
继续写点什么,任何东西。然后使用带有文字和图片的富有成效的对话来建立共同的理解。
Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.
使用故事的真正目的是共享理解。
The real goal of using stories is shared understanding.
敏捷开发中的故事得名于它们应该如何使用,而不是你写下来的内容。如果您在开发中使用故事,而不是使用文字和图片进行交流,那您就错了。
Stories in Agile development get their name from how they should be used, not what you write down. If you’re using stories in development and you’re not talking together using words and pictures, you’re doing it wrong.
如果您阅读本书的目的是学习写出更好的故事,那您就错了。
If your goal in reading this book is to learn to write better stories, you’ve got the wrong goal.
如果我给你看我的假期之一照片,你可能会看到我的孩子们在海滩上并礼貌地说,“那很可爱,”但当我看我的假期照片时,我记得夏威夷的一个特定海滩,我们不得不在一个深深的车辙上行驶一个多小时 -轮驱动小径,然后再徒步半小时穿过熔岩区即可到达。我记得我的孩子们抱怨,说没有什么值得这样做,而我也在想同样的事情。但它是。我们在一个令人难以置信的海滩上度过了幸福的一天,那里人很少,这就是为什么我们不厌其烦地到达那里。海龟们来到岸边晒沙子,这为这美好的一天锦上添花。
If I show you one of my vacation photos, you might see my kids on a beach and politely say, “That’s cute,” but when I look at my vacation photo, I remember a particular beach in Hawaii that we had to drive more than an hour on a deeply rutted four-wheel-drive trail, and then hike another half-hour over lava fields to get to. I remember my kids whining, saying nothing could possibly be worth this, and me wondering the same thing. But it was. We enjoyed a blissful day on an incredible beach where very few people were, which is why we took the trouble to get there. The turtles came up on the shore to bask on the sand, which was the icing on the cake of this fabulous day.
当然,如果你看照片,你不会知道所有这些,因为你不在那里。我记得这一切,因为我是。
Of course, if you look at the picture you won’t know all that because you weren’t there. I remember all that because I was.
无论好坏,这就是文档实际工作的方式。
For better or worse, this is the way documents actually work.
如果你参与了很多关于要构建什么软件的讨论,然后创建一个文档来理解它,你可能会与在场的其他人分享它。你们可能都同意这很好。但请记住,您的共同理解是在填写文档中没有的详细信息。其他不在场的读者不会从中得到与您相同的东西。即使她说她明白了,也不要相信她。聚集在一起,使用文档来讲述一个故事,就像我用我的假期照片告诉你我的故事一样。
If you participate in lots of discussions about what software to build, and then create a document to make sense of it, you might share it with someone else who was there. You might both agree it’s good. But remember, your shared understanding is filling in details that aren’t in the document. Another reader who wasn’t there won’t get the same things from it that you will. Even if she says she gets it, don’t believe her. Get together and use the document to tell a story the same way I used my vacation photo to tell you my story.
我听过有人开玩笑说,“我们正在使用敏捷过程,因为我们已经停止编写文档了。” 这对知道的人来说是个笑话,因为故事驱动的流程需要大量文档才能工作。但是这些文档并不总是看起来像传统的需求文档。
I’ve heard people joke, “We’re using an Agile process because we’ve stopped writing documents.” It’s a joke for people who know, because a story-driven process needs lots of documents to work. But those documents don’t always look at all like traditional requirements documents.
它需要谈话、素描、写作和使用便签或索引卡。它指向我们带入对话的文件,并用荧光笔和潦草的笔记标记它们。它具有互动性和高能量。如果您坐在会议桌旁,而一个人正在将您所说的话输入故事管理系统,那么您可能做错了。
It takes talking and sketching and writing and working with sticky notes or index cards. It’s pointing to documents we brought into the conversation and marking them up with highlighter and scribbled notes. It’s interactive and high energy. If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong.
当您讲故事时,几乎任何东西都可以用作交流的工具。当我们讲这些故事,写很多笔记,画很多图画时,我们需要保留它们。我们随身携带它们,以便稍后查看、拍照并重新输入更多文档。
When you’re telling stories, most anything can be used as a tool to communicate. And as we tell these stories, and write lots of notes, and draw lots of pictures, we need to keep them. We carry them around to look at later, photograph, and retype into more documents.
但是,请记住,最重要的不是写下来的内容——而是我们在阅读时记住的内容。这就是度假照片因素。
But, remember, what’s most important isn’t what’s written down—it’s what we remember when we read it. That’s the vacation photo factor.
交谈、素描、书写、使用便利贴和卡片,然后拍摄您的成果。更好的是,拍摄一段你在黑板上讨论内容的短片。你会记住很多你永远不可能记录下来的细节,而且非常深刻。
Talk, sketch, write, use sticky notes and cards, and then photograph your results. Even better, shoot a short video of you talking through what’s on the board. You’ll remember lots of details in a remarkable depth that you could never possibly document.
为帮助记忆,拍摄谈话结果的照片和短视频。
To help remember, photograph and shoot short videos of the results of your conversations.
There are lots of people who believe their job is collecting and communicating requirements. But it’s not.
事实上,你的工作是改变世界。
The truth is, your job is to change the world.
是的,我这么说是为了引起你的注意。而且,是的,我知道这听起来有点夸张。那是因为这个短语通常与世界和平、消除贫困或什至更牵强的目标有关,比如让政客们达成共识。但我是认真的。你将每一个伟大的想法转化为产品解决方案,都会以某种小的或不太小的方式为使用它的人改变世界。事实上,如果没有,你就失败了。
Yes, I said that to get your attention. And, yes, I know that sounds like hyperbole. That’s because that phrase is usually associated with world peace, eliminating poverty, or even more far-fetched goals like getting politicians to agree with one another. But I’m serious. Every great idea you turn into a product solution changes the world in some small, or not-so-small, way for the people who use it. In fact, if it doesn’t, you’ve failed.
有一个简单的、改变世界的模型,我个人使用并一直牢记在心,当你进行故事对话和建立共同理解时,你也需要将它牢记在心。
There’s a simple, change-the-world model that I personally use and keep in my head all the time, and you need to keep it in your head too while you’re having story conversation and building shared understanding.
我画的模型是这样的:
I draw the model like this:
该模型从观察现在的世界开始。当你看世界现在的样子时,你会发现人们不快乐、疯狂、困惑或沮丧。现在,世界很大,所以我们将主要关注使用我们制作的软件的人,或者我们希望使用它的人。当您查看他们在做什么以及他们使用的工具和他们做事的方式时,您会想出点子,这些点子可能用于:
The model starts by looking at the world as it is now. When you look at the world as it is now, you’re going to find people who are unhappy, mad, confused, or frustrated. Now, the world’s a big place, so we’ll focus mostly on the people who use the software we make, or the people we hope will use it. When you take a look at what they’re doing—and the tools they use and how they’re doing things—you’re going to come up with ideas, and the ideas might be for:
在某个时间点,您必须与其他人交流有关您的想法的详细信息,并且您可能会开始进行一些设计和规范。如果您打算将所有这些交给其他人,那么您确实可以将所有这些细节称为您的要求。但重要的是要记住,需求只是我们拥有的可以帮助人们的想法的别名。
At some point in time, you’ll have to communicate details about your ideas to some other people, and you might start to do some design and specification. If you’re going to hand all this off to someone else, then you might indeed call all these details your requirements. But it’s important to remember that requirements are just another name for the ideas we have that would help people.
鉴于这些要求,我们会经历一些导致交付的过程,然后产生一些实际登陆世界的软件,它会在以后登陆世界。我们希望的是,那些最初不开心、生气、沮丧或困惑的人会在该软件落地时变得快乐。现在,他们不高兴了,因为他们看到了它进来的那个漂亮的盒子——反正现在软件通常不装在盒子里了。他们不高兴,因为他们阅读了发行说明,或将应用程序下载到他们的移动设备上。他们很高兴,因为当他们使用软件、网站、移动应用程序或您构建的任何内容时,他们会以不同的方式做事——这就是让他们高兴的原因。
Given those requirements, we go through some process that results in a delivery, and out comes some software that actually lands in the world, and it lands in the world later. And what we hope is true is that those people who were initially unhappy, mad, frustrated, or confused will become happy when that software lands. Now, they’re not happy because they saw the pretty box it came in—software doesn’t usually come in boxes these days anyway. They’re not happy because they read the release notes, or downloaded the app to their mobile device. They’re happy because when they use the software, or the website, or the mobile app, or whatever you’ve built, they do things differently—and that’s what makes them happy.
现在,事实是你不能一直取悦所有人。你妈妈应该告诉你的。无论您生产什么,有些人都会比其他人更快乐,而有些人可能仍然不高兴,无论您工作多么努力,产品多么出色。
Now, the truth is that you can’t please everyone all of the time. Your mother should have told you that. Some people will be happier than others with whatever it is that you produce, and some might still be unhappy no matter how hard you’ve worked and how amazing your product might be.
想法和交付之间的一切都称为输出。这就是我们建造的。从事敏捷软件开发的人们会刻意测量输出速度并尝试加快他们的输出速度。当人们构建软件时,他们当然会关心他们正在做的事情的成本以及他们应该做的事情完成的速度。
Everything between the idea and the delivery is called output. It’s what we build. People working in Agile software development will deliberately measure velocity of output and try to speed up their rate of output. As people are building software, they are, of course, concerned about the cost of what they’re doing and the speed at which what they’re doing gets done, as they should be.
但是,虽然这是必要的,但输出并不是真正的重点;这不是我们真正想要的输出。这就是随之而来的结果。这叫做结果。结果是事情发生时发生的事情——这就是为什么它被这样称呼——这很困难,因为在事情发生之前我们无法衡量结果。而且我们不会根据交付的功能数量或人们现在有能力做什么来衡量结果。我们衡量的是,由于您所构建的内容,人们为实现目标所做的实际不同,最重要的是,您是否让他们的生活变得更美好。[ 2 ]
But, while it’s necessary, the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome. Outcome is what happens when things come out—that’s why it’s called that—and it’s difficult because we don’t get to measure outcome until things do come out. And we don’t measure outcome by the number of features delivered, or what people have the capability to now do. We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives better.[2]
就是这样。你改变了世界。
That’s it. You’ve changed the world.
你在其中加入了一些东西,改变了人们实现目标的方式,当他们使用它时,世界对他们来说是不同的。
You’ve put something in it that changes the way people can reach their goals, and when they use it, the world is different for them.
如果您还记得的话,您的目标不仅仅是构建新产品或功能。当您就该功能进行对话时,您会谈论它是为谁服务的,他们现在做什么,以及以后的事情会如何改变。后来的积极变化才是他们想要它的真正原因。
If you remember, your goal isn’t to just build a new product or feature. When you have conversations about that feature, you’ll talk about who it’s for, what they do now, and how things will change for them later. That positive change later is really why they’d want it.
好的故事对话是关于谁和为什么,而不仅仅是什么。
Good story conversations are about who and why, not just what.
我和下一个人一样关心别人,但说实话,这不仅仅是让人们开心。如果你为一家为你和其他人支付报酬的公司工作,你必须关注最终帮助你的组织赚取更多收入、保护或扩大其市场或更有效运营的因素。因为,如果您的公司不健康,那么您将没有资源(或工作)来帮助任何人。
I care about people as much as the next guy, but truthfully, it’s not just about making people happy. If you work for a company that pays you and others, you’ve got to focus on what ultimately helps your organization earn more, protect or expand its market, or operate more efficiently. Because, if your company isn’t healthy, then you won’t have the resources (or the job) to help anyone.
所以我必须稍微修改一下这个模型。它实际上是从审视您的组织内部开始的。在那里你会发现更多不快乐的人。这通常是因为业务表现不如他们希望的那样。为了解决这个问题,他们可能有想法关注特定的客户或用户,并制作或改进他们正在使用的软件产品。你看,它最终是关于人的,因为:
So I’ve got to revise this model a bit. It actually starts by looking inside your organization. There you’ll find even more people who aren’t happy. And it’s usually because the business isn’t performing as well as they’d hope. To fix this, they may have ideas to focus on specific customers or users and to make or improve the software products they’re using. You see, it ultimately is about people, because:
除非您的客户和用户得到他们想要的东西,否则您的公司无法得到它想要的东西。
Your company can’t get what it wants unless your customers and users get something they want.
通过选择要关注的人、要解决的问题以及将想法转化为工作软件,流程继续进行。从那里开始——如果客户购买,用户使用它,人们感到高兴——最终赞助这一开发的企业将看到它正在寻找的好处。这将反映在收入增加、运营成本降低、客户更满意或市场份额扩大等方面。这让贵公司内部的很多人都很高兴。它也应该让你快乐,因为你刚刚帮助你的公司保持健康,同时在这个过程中让人们的生活变得更好。这是双赢的。
The flow continues by choosing the people to focus on, the problems to solve, and the ideas to turn into working software. And from there—if the customers buy, and the users use it, and people are happy—eventually the business that sponsored this development will see the benefit it’s looking for. That’ll be reflected in things like increased revenue, lower operational costs, happier customers, or expanded market share. This makes lots of people inside your company happy. It should make you happy, too, since you’ve just helped your company stay healthy while making real people’s lives better in the process. It’s a win-win.
这是由于良好结果而发生的长期事情,我将其标记为影响。结果通常是您可以在分娩后立即观察到的。但影响需要更长的时间。
It’s that longer-term stuff that happens as a consequence of good outcomes that’s I’ll label impact. Outcomes are often something you can observe right away after delivery. But impact takes longer.
软件世界有一个令人不安的事实,我怀疑很多其他地方也是如此。但我懂软件。我所知道的是:
There’s an uncomfortable truth about the software world, and I suspect it’s true of lots of other places. But I know software. And what I know is that:
总是有比我们有时间或资源要构建的更多的东西——总是如此。
There’s always more to build than we have time or resources to build—always.
软件开发中的一个常见误解是我们试图更快地获得更多输出。因为如果有太多事情要做,那么做得更快会有所帮助,对吧?但如果你玩对了游戏,你就会意识到你的工作不是建造更多——而是建造更少。
One of the common misconceptions in software development is that we’re trying to get more output faster. Because it would make sense that if there was too much to do, doing it faster would help, right? But if you get the game right, you will realize that your job is not to build more—it’s to build less.
最小化输出,最大化结果和影响。
Minimize output, and maximize outcome and impact.
归根结底,您的工作是最大限度地减少产出,并最大限度地提高成果和影响。诀窍在于你必须密切关注那些你正在努力解决其问题的人。这些包括将选择购买软件来解决其组织中的问题的人、选择者,以及使用它的人、用户。有时他们是同一个人。有时他们不是。
At the end of the day, your job is to minimize output, and maximize outcome and impact. The trick is that you’ve got to pay close attention to the people whose problems you’re trying to solve. These include the people who will choose to buy the software to solve a problem in their organizations, the choosers, as well as the people who use it, the users. Sometimes they’re the same people. Sometimes they’re not.
您的企业有很多可以关注的潜在用户和客户。您的业务战略应该为您提供一些指导,让您了解应该关注哪些人才能获得您想要的影响。我向你保证,没有一家企业拥有让每个人都开心的资源——这是不可能的。
Your business has lots of possible users and customers it could focus on. Your businesses strategy should give you some guidance about who to focus on to get the impact you want. I promise you that no business has the resources to make everyone happy—it’s just not possible.
别误会我的意思。更快地构建更多软件总是一个好主意。但这永远不是解决方案。
Don’t get me wrong here. Building more software faster is always a good idea. But it’s never the solution.
在我软件职业生涯的几乎整个头十年,我都在为实体零售商构建软件,我没有使用需求这个词——至少,没有太多。这不是我正在做的事情的相关术语。我有很多不同的客户,他们对什么可以帮助他们都有具体的想法。我也知道我在一家必须通过销售我的产品来赚钱的公司工作。事实上,我在贸易展上花了很长时间,帮助我的公司向各种各样的客户销售产品。最终,我知道在我和我的团队开发的产品交付后,我必须继续与这些客户合作,因此我努力工作,为他们的最大利益服务。这意味着我不能给每个人他们想要的一切,因为他们想要不同的东西。我的公司和团队没有无限的时间,所以我必须努力工作,找出我能做的最少的事情来让人们开心。这听起来可能令人沮丧,但这实际上是有趣的部分。
For almost the entire first decade of my software career, which I spent building software for brick-and-mortar retailers, I got away without using the word requirements—at least, not much. It just wasn’t a relevant term for what I was doing. I had lots of different customers who all had specific ideas about what would help them. I also knew I worked for a company that had to make money by selling my product. In fact, I’d spent long hours standing at trade shows helping my company sell its product to a wide variety of customers. I knew at the end of the day that I would have to continue to work with those customers after I shipped the products my team and I developed, and so I diligently worked to act in their best interest. This meant I couldn’t give everyone everything they wanted, because they wanted different things. And my company and team didn’t have infinite time, so I had to work hard to figure out the least I could build to make people happy. That may sound frustrating, but it’s actually the fun part.
随着公司的发展,我们增加了更多的传统软件人员。有一次,另一个团队的负责人来找我说,“杰夫,我需要你对你正在开发的产品进行这些更改。”
As the company grew, we added more traditional software people. At one point, the head of a different team came to me and said, “Jeff, I need you to make these changes to the product you’re working on.”
我说:“很好,没问题。告诉我他们是为谁服务的,这为他们解决了哪些问题。”
I said, “Great, no problem. Tell me who they’re for and what problems this solves for them.”
她的回应?“他们是要求。”
Her response? “They’re the requirements.”
我回答说:“我明白了。只需告诉我一些关于他们是为谁服务的,他们将如何使用它,以及它适合他们工作方式的哪些地方。”
I replied, “I get it. Just tell me a bit about who they’re for, and how they’re going to use this, and where it fits into the way they work.”
她看着我,就像我是个傻子一样,最后一次对我说,“他们是要求。”
She looked at me like I was stupid and said to me one last time with an air of finality, “They’re requirements.”
那一刻我才知道要求这个词其实就是闭嘴的意思。
It was at that moment that I learned that the word requirements actually means shut up.
对于很多人来说,这正是需求的作用。他们停止谈论人和我们正在解决的问题。事实是,如果你构建的只是所需内容的一小部分,你仍然可以让人们非常开心。[ 3 ]
For a great many people, that’s exactly what requirements do. They stop conversations about people and the problems we’re solving. The truth is, if you build a fraction of what’s required you can still make people very happy.[3]
记住:归根结底,你的工作不是满足需求——你的工作是改变世界。
Remember: at the end of the day, your job isn’t to get the requirements right—your job is to change the world.
如果您从本书中没有得到任何其他信息,请记住以下几点:
If you get nothing else from this book, remember these things:
故事的本意是以一种完全不同的方式来思考我们共同创造软件所面临的挑战——以及许多其他事情,就此而言。如果你们能有效地合作并创造解决问题的东西,你们将统治世界。或者至少其中的一小部分被您的产品所占据。
Stories as they’re intended are a completely different way of thinking about the challenges we face working together to create software—and lots of other things, for that matter. If you can work together effectively and create things that solve problems, you will rule the world. Or at least some small part of it inhabited by your products.
当您阅读本书时,我希望您能回到使用故事的基础知识。我希望您与其他人一起工作,讲述您的用户和客户的故事,以及您可以如何帮助他们。我希望你画画,并制作大型便签纸模型。我希望你感到参与和创造性。我希望你觉得你正在有所作为。因为当你做对的时候,你就是。而且它也更有趣。
As you read this book, my hope is that you get back to the basics of using stories. I hope you work together with others, telling stories about your users and customers and how you can help them. I hope you draw pictures, and build big sticky-note models. I hope you feel engaged and creative. I hope you feel like you’re making a difference. Because when you do it right, you are. And it’s a lot more fun, too.
现在是时候谈谈讲故事可能带来的最大乐趣了,那就是您使用故事地图的时候。
Now it’s time to talk about the most fun you can possibly have telling stories, and that’s when you’re using a story map.
[ 1 ]有很多文章试图描述火星轨道器出了什么问题。这是其中之一:http ://www.cnn.com/TECH/space/9909/30/mars.metric.02/ 。
[1] There are a lot of articles that try to describe what went wrong with the Mars Orbiter. Here’s one of them: http://www.cnn.com/TECH/space/9909/30/mars.metric.02/.
[ 2 ]在罗伯特·法布里坎特 (Robert Fabricant) 的一次名为“行为是我们的媒介”的演讲中,我首先清楚地了解了简洁的语言以及输出和结果之间的区别。在此之前,我一直在为脑海中清晰的语言而苦苦挣扎——其他人也是如此。令人高兴的是,罗伯特的头脑很清楚。
[2] The clean language and distinction between output and outcome was first made clear to me in a talk by Robert Fabricant called “Behavior Is Our Medium”. Prior to that, I’d struggled with language that was clear in my head—and everyone else’s too. Happily, it was clear in Robert’s head.
“我喜欢敏捷开发!每隔几周我们就会看到更多可用的软件。但感觉就像我失去了大局。”
“I love Agile development! Every few weeks we see more working software. But it feels like I’ve lost the big picture.”
如果我每次从敏捷团队成员那里听到类似的话都能得到一毛钱,那么我会有……好吧……很多毛钱。我经常听到。你甚至可能自己也说过类似的话。好吧,我有好消息要告诉你。使用敏捷流程和故事驱动的方法并不意味着您必须牺牲大局。你仍然可以对你的整个产品进行健康的讨论,并且仍然每隔几周就能看到进展。
If I had a dime for every time I heard something like that from an Agile team member, I’d have…well…a lot of dimes. I hear it a lot. You may have even said something like that yourself. Well, I’ve got good news for you. Using an Agile process and a story-driven approach doesn’t mean you have to sacrifice the big picture. You can still have healthy discussions about your whole product and still see progress every few weeks.
由于您已经耐心地阅读了“首先阅读本章”一章,我将绕过所有关于故事的垃圾内容,直接进入故事地图如何解决敏捷开发中最大的问题之一。如果您已经熟悉编写有关敏捷项目的故事,那么本章可能足以让您入门。
Since you’ve patiently read the “Read This First” chapter, I’m going to bypass all the junk about stories and proceed directly to how story maps solve one of the biggest problems in Agile development. If you’re already familiar with writing stories on Agile projects, this chapter may be enough to get you started.
如果您正在阅读本书,您可能知道故事映射是一种处理用户故事的方法,因为它们被用于敏捷流程。现在,正是在这一点上,所有其他与敏捷开发有关的书都在重现“敏捷软件开发宣言”,那是 2001 年由 17 个人写的东西,他们对正在发生的一些适得其反的大过程趋势感到沮丧时间。我很高兴他们写了它。我很高兴许多人都感受到了他们工作的影响。
If you’re reading this book, you likely know that story mapping is a way to work with user stories as they’re used in Agile processes. Now, it’s at this point that every other book that has something to do with Agile development reproduces the “Manifesto for Agile Software Development,” that thing written in 2001 by 17 guys who were frustrated with some of the big counterproductive process trends going on at the time. I’m glad they wrote it. And I’m glad that the impact of their work has been felt by so many.
但很抱歉让你失望了——我不会重印宣言并滔滔不绝地谈论它的重要性。我相信你已经知道为什么会这样。而且,如果您还没有阅读宣言,那么您应该阅读。
But I’m sorry to disappoint you—I’m not going to reprint the manifesto and gush about why it matters. I believe you already know why it does. And, if you haven’t read the manifesto, then you should.
在宣言本应在本章中占据的空间中,我加入了一张有趣的小猫照片。[ 4 ]为什么?因为一次又一次地证明,有趣的小猫照片在互联网上获得的关注远远超过任何宣言所希望的。
In the space that the manifesto would have taken up in this chapter, I am instead including a funny kitten photo.[4] Why? Because it has been proven time and time again that funny kitten photos on the Internet get far more attention than any manifesto could ever hope to.
那么,您可能想知道,这只小猫与敏捷有什么关系?其实,没什么。但敏捷肯定与这本书有关,与故事和故事映射的演变有关。
So, you might wonder, what does this kitten have to do with Agile? Actually, nothing. But Agile definitely has something to do with this book, and with stories and the evolution of story mapping.
<提示闪回音乐……>
<Cue the flashback music…>
2000 年,我在旧金山的一家初创公司工作,该公司聘请了Kent Beck(创建极限编程并首先描述故事概念的人)作为顾问让软件开发过程继续进行。我倒回去了,但重要的是这个故事的想法是一个古老的想法。如果您刚刚开始使用故事,那么您将失去十年前可能拥有的任何早期采用者身份。Kent 和其他开创了极限编程的人都知道,过去所有这些处理需求的方法都不太奏效。肯特的简单想法是我们应该聚在一起讲述我们的故事;通过交谈,我们可以建立共同的理解,并共同达成更好的解决方案。
I was working at a startup in San Francisco in 2000, and the company had hired Kent Beck (the guy who created Extreme Programming and first described the idea of stories) as a consultant to get the software development process going. I’m rewinding way back, but the important thing is this story idea is an old one. If you’re just starting out with using stories, you lost any early adopter status you could have had a decade or so ago. Kent and others who pioneered Extreme Programming knew that all those ways of doing requirements in the past didn’t work out well. Kent’s simple idea was that we should get together and tell our stories; that by talking we could build shared understanding, and together we’d arrive at better solutions.
当我第一次听到故事这个词时,它让我感到困扰。我会承认的。我们通过将人们想要的重要事物称为故事来贬低它们的想法似乎并不正确。但我学得慢——这是我之前在讨论共享理解时提出的一点。我花了一段时间才真正明白:
When I first heard the term story, it bugged me. I’ll admit it. The idea that we’d trivialize the important things that people wanted by calling them stories didn’t seem right. But I’m a slow learner—a point I brought up earlier when discussing shared understanding. It took me a while to really get that:
故事得名于它们应该如何使用,而不是应该写什么。
Stories get their name from how they should be used, not what should be written.
甚至在我真正理解为什么故事有这个名字之前,我就意识到我可以在便利贴或卡片上写下一堆故事——一句话或一个简短的标题。我可以四处移动它们并确定它们的优先级,以决定哪个更重要。一旦我确定一个比另一个更重要,我们就可以开始讨论它。这太酷了。为什么我以前从来没有在卡片上写过东西并以这种方式组织它们?
Even before I’d really understood why stories had that name, I realized that I could write down a bunch of stories—a sentence or a short title—on sticky notes or cards. I could move them around and prioritize them to decide which one was more important. Once I decided that one was more important than another, then we could start having a discussion about it. This was super-cool. Why hadn’t I ever written things on cards and organized them this way before?
问题是这张卡片可能只需要软件开发人员几个小时就可以添加到产品中,或者可能需要几天或几周,或者一个月——谁知道呢?我没有——至少在我们开始谈论它之前没有。
The problem was that this one card could be something that might take a software developer just a couple hours to add to a product, or maybe a couple days or a couple weeks, or maybe a month—who knew? I didn’t—at least not until we started talking about it.
当我开始故事对话并了解到我的故事太大时,我在处理我的第一个敏捷项目的故事时陷入了激烈的争论。我希望在下一次迭代中完成这个故事。与我交谈的开发人员告诉我情况并非如此。我觉得我做错了什么。开发人员确定了我们可以讨论的一小部分,可以在我们的下一次迭代中完成。但我很沮丧,因为我们不能谈论大局。我真的很想了解我真正需要的大事需要多少时间。我希望这次讨论能够实现这一点,但它没有。
I got into a nasty argument while working with stories on my very first Agile project when I began a story conversation and learned that my story was too big. I’d hoped to get this story done in the next iteration. The developers I spoke with informed me otherwise. I felt like I’d done something wrong. The developers identified a small part we could talk about that could be accomplished in our next iteration. But I left frustrated that we couldn’t talk about the big picture. I really wanted to understand how much time the big thing I really needed would take. I’d hoped this discussion would accomplish that, and it didn’t.
2001 年,我离开了我所在的团队,开始以不同的方式做事。我和我的团队尝试了一种着眼于大局的故事写作方法。我们努力了解我们正在构建的产品并共同做出权衡。我们使用那一堆带有故事标题的索引卡来组织我们的想法,并将大图分解成我们接下来可以构建的小部分。2004 年,我写了第一篇关于这个想法的文章。然而,直到 2007 年,我才创造出故事地图这个词。
In 2001 I left the team I was on and started doing things differently. I, and my team, tried an approach to writing stories that focused on the big picture. We worked to understand the product we were building and to make tradeoffs together. We used that bunch of index cards with story titles to organize our thoughts and break down that big picture into the small parts we could build next. In 2004, I wrote my first article about this idea. I didn’t coin the term story mapping, however, until 2007.
事实证明,你给某物起的名字很重要。正是在给这种做法起了好名字之后,我才真正看到它传播开来。当时我认为这是一项伟大的发明——也就是说,直到我开始遇到更多的人在做类似的事情,如果不是完全相同的话。我发现了一个规律。
It turns out that the name you give something matters. It was after giving the practice a good name that I really saw it spread. I thought it was a great invention at the time—that is, until I started running into more people who were doing similar if not exactly the same things. I’d discovered a pattern.
我第一次从我的朋友 Linda Rising 那里听到模式的这个定义:当你告诉某人一个好主意,他说,“是的,我们也做类似的事情。” 这不是发明,这是一种模式。
I first heard this definition of a pattern from my friend Linda Rising: when you tell someone about a great idea and he says, “Yeah, we do something like that, too.” It’s not an invention, it’s a pattern.
故事映射是一种模式。这是明智的人为了理解整个产品或整个功能所做的事情。这是他们将大故事分解成小故事的方法。如果您没有自己到达目的地,请不要感到难过。你最终会的。但是阅读这本书会让你避免数周或数月的挫败感。
Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones. Don’t feel bad if you didn’t arrive at it on your own. You would have eventually. But reading this book will save you weeks or months of frustration.
故事地图用于分解您讲述的大故事。
Story maps are for breaking down big stories as you tell them.
如今,一家又一家公司采用了故事地图的理念。我在 SAP 的朋友 Martina 在 2013 年 9 月发送的消息中说:
Today, company after company has adopted the idea of story mapping. My friend Martina at SAP said in a message she sent in September 2013 that:
……此时已经正式记录了 120 多个 USM [用户故事映射] 研讨会。很多 PO 只是简单地喜欢它!这只是 SAP 行之有效的方法。
…at this point more than 120 USM [User Story Mapping] workshops have officially been recorded. A lot of POs just simply love it! It is simply a well-established approach at SAP.
每周我都会听到来自其他地方的其他人告诉我绘图故事如何帮助他们解决问题。这些天来,我从与他人交谈中学到的东西比我自己学到的要多。
Every week I hear from someone else from somewhere else telling me how mapping stories helped solve a problem for them. These days, I learn more from talking to others than I ever could on my own.
故事的最初想法很简单。它使我们的注意力从共享文档转向共享理解。使用故事的一种常见方法是建立一个故事列表,确定它们的优先级,然后开始谈论它们,然后将它们一次一个地转化为软件。当你听到它时,这听起来很合理。但它会产生一些大问题。
The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding. A common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time. That sounds pretty reasonable when you hear about it. But it can create some big problems.
几年前我遇到了加里莱维特。加里是一名正在推出新网络产品的商人。网络产品现在就在那里,它被称为 Mad Mimi,当 Gary 构思他的产品时,它是音乐行业营销界面的缩写。[ 5 ]加里是一位拥有自己乐队的音乐家。他管理自己的乐队,帮助管理其他乐队,同时也是一名录音室音乐家,为客户创作唱片。
A few years ago I met Gary Levitt. Gary was a businessperson in the process of launching a new web product. The web product is out there right now, and it’s called Mad Mimi, which when Gary conceived of his product, was short for music industry marketing interface.[5] Gary is a musician who had his own band. He managed his band, helped manage others, and was also a studio musician and created recordings for clients.
我遇见加里的那天,他接到了奥普拉·温弗瑞 (Oprah Winfrey) 节目的订单,需要几十个前奏和结尾,以及一些用于广告和类似内容的音乐片段。电视节目的制作人购买它们的方式就像排版时事通讯的人购买剪贴画一样,所以它就像音频剪贴画一样。加里有一个相当大的应用程序的想法,可以帮助像他这样的音乐家和他认识的人在他正在从事的项目中相互合作,以及乐队经理和音乐家需要做的许多其他事情管理和推广他的乐队。
The day I met Gary he had an order from the Oprah Winfrey show for dozens of intros and outros, little bits of music that are used to go out to and come in from commercials and things like that. Producers of television shows buy those the way people laying out a newsletter buy clip art, so it’s like audio clip art. Gary had an idea for a fairly big application that would help musicians like him and people he knew to collaborate with one another on projects like the one he was working on, along with lots of other things a band manager and musician would need to do to manage and promote his band.
Gary 想要构建软件,所以他和某人一起工作,而那个人正在以敏捷的方式工作。那个人告诉加里写下他想要的所有东西的清单,对清单进行优先排序,然后他们会讨论价值最高的东西——最重要的东西——然后开始逐一构建它们。这份清单就是敏捷流程所称的待办事项列表,Gary 创建清单并首先从最重要的事情开始似乎是有意义的。所以这就是他所做的。
Gary wanted to get the software built so he worked with somebody, and that somebody was working in an Agile way. That person told Gary to write down a list of all the things he wanted, prioritize the list, and then they would talk about the highest-valued things—the most important—and start building them one at a time. That list of things is what Agile processes refer to as a backlog, and it seemed to make sense to Gary to create the list and start with the most important things first. So that’s what he did.
加里创建了他的积压工作,开发团队开始一次构建一些东西。与此同时,加里继续为每一个构建的软件支付费用,导致现金流失。该软件正在慢慢成型,但加里可以看出,它需要更长的时间才能符合他的设想,而且他很早就会用完现金。
Gary created his backlog and the development team started building things a bit at a time. In the meantime, Gary was hemorrhaging cash as he continued to pay for each piece of software that was built. The software was slowly taking shape, but Gary could tell it was going to take a lot longer for it to match his vision and he was going to run out of cash long before then.
我认识和加里一起工作的人。我的朋友知道加里压力很大,想帮助他。我认识的人问我是否可以与加里交谈,与他交谈并帮助他组织他的想法。我联系了加里并安排在他位于曼哈顿的办公室与他会面。
I knew the person who was working with Gary. My friend knew Gary was stressing out and wanted to help him. The somebody I knew asked if I could have a conversation with Gary, to talk with him and help him get his ideas organized. I contacted Gary and made arrangements to meet him at his office in Manhattan.
加里和我开始交谈。在他说话的同时,我根据他所说的要点写了卡片。在构建故事地图时,我喜欢一句口头禅。我会说“talk and doc”(动词文档的缩写),这基本上意味着不要让你的话蒸发。将它们写在卡片上,以便您以后可以参考。你会注意到指向卡片上的几个词如何快速帮助每个人回忆起关于它的对话。我们可以在桌子周围滑动它们,在那里我们可以重新组织它们。当我们指向卡片时,我们开始使用这样那样有用的词。它可以节省很多时间。帮助加里具体化他的想法对于获得共同理解至关重要。这对他来说不是一个习惯,所以我很容易在他讲故事的时候写卡片。
Gary and I started talking. And as he talked, I wrote cards with key points from what he said. There’s a mantra that I like when I build story maps. I’ll say “talk and doc” (short for the verb document), which basically means don’t let your words vaporize. Write them down on cards so you can refer back to them later. You’ll notice how pointing to a few words on a card quickly helps everyone recall the conversation about it. We can slide them around the table where we can reorganize them. We start using useful words like this and that as we point to cards. It saves lots of time. Helping Gary externalize his thoughts was critical to getting shared understanding. It wasn’t a habit for him, so it was easy for me to write the cards as he told the story.
谈话和记录:写卡片或便利贴,在讲故事时将您的想法具体化。
Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.
我们首先将卡片放在桌面上,但很快就用完了。我拜访他的那天,加里正在搬办公室,他所在的纽约市阁楼里的大部分家具都在地板上。因此,我们将不断增长的卡片地图移到了地板上。
We started by placing cards on a tabletop, but quickly ran out of space. Gary was moving offices the day I visited with him, and much of the furniture in the New York City loft where he was located was off the floor. So we moved our growing map of cards onto the floor.
在一天结束时,地板看起来像这样:
At the end of the day, the floor looked like this:
我不是来这里了解 Gary 的要求的。我们谈论的第一件事不是功能列表。我们不得不后退一点,从头开始。
I wasn’t here to capture Gary’s requirements. And the first thing we talked about wasn’t that list of features. We had to back up a bit and start at the beginning.
我们的第一次谈话集中在构建他的产品理念上。我们谈论了他的生意和他的目标。你为什么要建这个?告诉我对您和使用它的人的好处。它为那些人和你解决了什么问题?当您阅读本文时,您可能会发现我脑子里已经有了那个现在和以后的模型。我试图了解 Gary 正在寻找的结果,而不是他想要构建的输出。
Our first conversation focused on framing his product idea. We talked about his business and what his goals were. Why are you building this? Tell me about the benefits for you and for the people who will use this. What problems does it solve for those people and for you? As you read this you might detect I’ve got that now-and-later model in my head. I’m trying to understand the outcomes Gary is looking for, not the output he wants to build.
如果我放下两张牌,一张放在另一张上面,那么人们就会认为上面的一张更重要。一言不发,如果我只是把一张卡片滑到另一张上面,我已经指出了一些重要的事情。尝试使用目标列表。故意将它们按错误的顺序排列,然后看着与您一起工作的人伸出手来调整它们。我对加里和他的目标做了这个,这帮助他表达了对他来说更重要的东西。
If I put two cards down, one above the other, then people assume that the one above is more important. Without saying a word, if I simply slide a card above another, I’ve indicated something about importance. Try that with a list of goals. Purposely put them in the wrong order and watch the person you’re working with reach out to adjust them. I did this with Gary and his goals, and it helped him express what was more important to him.
加里和我继续交谈和记录。加里和我的下一次谈话是关于购买他的软件的客户和使用他的软件的用户。我们列出了不同类型的用户。我们讨论了他们会得到什么好处,并询问他们为什么要使用该产品以及我们认为他们会用它做什么。这对他们有什么好处?我们建造了一大堆。这些卡片似乎自然而然地落在一堆最重要的用户身上。有趣的是,它是如何在没有明确决定的情况下以这种方式运作的。
Gary and I continued to talk and doc. The next conversation Gary and I had was about the customers who would buy, and users who would use, his piece of software. We listed the different types of users. We talked about what benefits they would get, and asked why they would use the product and what we thought they would do with it. What was in it for them? We built a big pile of those. The cards naturally seemed to fall with most important users higher in the pile. Funny how it works out that way without an explicit decision.
在我们讨论任何细节之前,我已经看出 Gary 的远见卓识。软件开发的一个严峻现实是,要构建的东西总是超出我们的时间和金钱。因此,目标永远不应该是全部构建。目标是尽量减少我们建造的数量。所以我问加里的第一个问题是,“在所有这些不同的用户和他们想做的事情中,如果我们只专注于让其中一个用户兴奋,那会是谁?”
Before we’d gone into any detail at all, I could already see that Gary’s vision was big. One of the tough realities about software development is that there’s always more to build than we have time and money for. So the goal should never be to build it all. The goal is to minimize the amount we build. So the first question I asked Gary was, “Of all these different users and the things they want to do, if we were to focus on thrilling just one of those users, who would it be?”
加里选择了一个,我们开始真正讲故事。
Gary chose one and we started to really tell stories.
接下来我说,“好吧,让我们想象一下未来。让我们暂时假设这个产品是实时的,让我们谈谈使用它的人生活中的一天并开始讲述这个故事。首先,他们会做这个,然后做这个,依此类推。” 我们从左到右依次讲述这个故事。有时我们回溯并将一些东西放在其他东西的左边,因为它们在卡片上,我们可以很容易地重新排列它们。
I next said, “OK, let’s imagine the future. Let’s assume for a minute this product is live and let’s talk about a day in the life of someone who uses it and start telling the story. First, they would do this, and then this, and so on and so on.” And we told the story in a flow from left to right. Sometimes we backtracked and put things to the left of other things, and because they were on cards, we could easily rearrange them.
使用卡片时自然会发生的另一件有趣的事情是,如果我把一张放在左边,另一张放在右边,我一言不发,我已经指出了顺序。这对我来说有点神奇——但我很容易被娱乐。我惊叹于我们可以不言而喻地交流多少。
The other interesting thing that happens naturally when working with cards is if I put one to the left and another to the right, without saying a word I’ve indicated sequence. This is kind of magical for me—but I’m easily entertained. I marvel at how much we can communicate without saying a word.
将卡片重新整理在一起可以让您无需说一句话即可进行交流。
Reorganizing cards together allows you to communicate without saying a word.
当我们交谈和记录时,以及当我写下我们的谈话时,我们正在构建一些非常重要的东西。不,不是地板上那一堆卡片。真正重要的是共同理解。我们正在达成共识。这是 Gary 以前从未与任何人就他的产品创意做过的事情,至少在这种细节级别上没有。他自己从来没有想过这么多。高潮在他的脑海里,有点像你在电影预览中看到的动作场面。
As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding. We’re getting on the same page. This is something Gary had never done with anyone before about his product idea, at least not at this level of detail. He’d never even given it this much thought himself. The high points were in his head, sort of like the action scenes you’d see in a movie preview.
在此之前,加里已经完成了他被要求做的事情。他写了一堆故事标题,把它们列在一张清单上,然后一次一个地谈论它们。谈话更多的是关于构建什么的细节,而不是大局。加里的大局中有很多漏洞。你会发现,无论你对你的故事有多清楚,在你绘制地图的时候通过它来谈论它会帮助你发现你自己思维中的漏洞。
Before now, Gary had done what he was asked to do. He’d written a bunch of story titles, put them in a list, and talked about them one at a time. The conversations were more about the details of what to build and less about this big picture. And there were a lot of holes in Gary’s big picture. You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking.
映射您的故事可以帮助您找到思维中的漏洞。
Mapping your story helps you find holes in your thinking.
随着我们深入挖掘,我们意识到这个故事也不只是关于一个用户。加里 (Gary) 从一位乐队经理开始,他想宣传他的乐队以及他正在做的工作,以创建宣传并将其通过电子邮件发送给粉丝。然后我们很快不得不谈论乐队的粉丝,并讲述她看到宣传然后计划去看演出的故事。
As we dug deeper, we realized that the story also wasn’t just about one user. Gary’s started with a band manager who wanted to promote his band and the work he was doing to create the promotion and email it to fans. Then we quickly had to talk about the fan of the band, and tell her story about seeing the promotion and then making plans to see a show.
然后,如果我们在某个地方宣传乐队,我们需要讲述场地经理的故事以及他想了解有关宣传的信息。到这个时候,我们的地图已经足够宽了,以至于我们撞到了墙上,所以我们不得不在第一层下面的另一层继续这个故事。这就是为什么照片中的地图有两层。
Then, if we were promoting the band someplace, we’d need to tell the story of the venue’s manager and the information he’d like to learn about the promotion. By this time, our map was wide enough that we bumped into the wall, so we had to continue the story in another layer below the first. That’s why the map in the photograph has two layers.
在讲故事的过程中,有时 Gary 会讲到他很兴奋的部分,然后他会开始描述很多细节。一张卡在另一张上面可以表示优先级。但它也可以表示分解,这只是一个花哨的词,表示较小的细节是更大事物的一部分。正如加里描述的细节,我会把它们记录在一张卡片上,并将它们放在上面大用户步骤的下面。例如,当加里描述制作乐队经理用来宣传演出的传单时,他格外热情,并且有很多细节需要讨论。
During the story, sometimes Gary would get to a part where he was excited and he’d start describing lots of details. One card above another can indicate priority. But it can also mean decomposition, which is just a fancy word for smaller details that are part of a bigger thing. As Gary described the details, I’d record them on a card, and place them below the big user step above. For instance, when Gary described creating the flyer that band managers would use to promote their gigs, he was extra passionate and had lots of details to discuss.
加里住在纽约市,当乐队撰写传单时,他想象着他看到的所有这些非常酷的东西都贴在纽约的墙壁和灯柱上。它们可能看起来像是用胶水和胶带粘在一起然后复印的,但有些真的很优雅和艺术。记录了一些细节后,我说,“我们回过头来再谈细节。让我们继续前进,让这个故事向前发展。” 很容易迷失在细节中,尤其是那些你热衷的细节。但是,当我们试图了解全局时,重要的是在了解所有这些细节之前先了解故事的结尾。至少在这个阶段,我在制图时使用的另一个口头禅是“一英里宽,一英寸深”——或者对于使用公制系统的理智国家的人来说:“一公里宽,一厘米深”。在迷失细节之前先了解故事的结尾。
Gary lived in New York City, and when bands are composing flyers he’s imagining all these really cool things he sees stuck on walls and lampposts in New York. They might look like they were put together with glue and tape and then photocopied, but some were really elegant and artistic. After recording a handful of details, I said, “Let’s come back and get to the details later. Let’s continue on and move this story forward.” It’s easy to get lost in the details, especially the ones you’re passionate about. But, when we’re trying to get the big picture, it’s important to get to the end of the story before catching all those details. Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—or for people in sane countries using the metric system: “kilometer wide, centimeter deep.” Get to the end of the story before getting lost in the details.
在深入研究之前,先关注故事的广度。
Focus on the breadth of the story before diving into the depth.
最终我们确实走到了加里故事的结尾。乐队经理成功地向成千上万的粉丝宣传了一场演出,演出取得了巨大的成功。到目前为止,我们的产品愿景都很清晰。我说,“现在让我们回去填写细节并考虑一些备选方案。”
Eventually we did get to the end of Gary’s story. The band manager had successfully promoted a gig to thousands of fans who spread the word, and the show was a wild success. The product vision so far was clear in both our heads. I said, “Now let’s go back and fill in the details and consider some of the alternatives.”
在我们确定了故事地图的广度之后,它开始变厚。我们放在地图中每一列顶部的卡片变成了大东西,然后细节分解在它们下面。我们在用户故事的每一步停下来询问:
After we’ve got the breadth of the story map in place, it starts thickening up. The cards we put at the top of each of the columns in the map become big things, and then the details break down below them. We stop at each step in the user’s story and ask:
最后,我们回去填写了很多细节。结果是我们讲述了乐队经理一天的生活故事,以及对乐队经理的成功很重要的其他人:粉丝和场地经理。
At the end of this we’d gone back and filled in a lot of details. The result was that we had told the story about a day in the life of a band manager, as well as the other people important to the band manager’s success: fans and venue managers.
我问加里,“现在呢?我们有所有这些其他用户,还有他们想做的其他事情——你想谈谈他们吗?你可以看到,如果我们继续谈话,我们将需要一个更大的房间。而且,加里,如果你做所有这些事情,那么构建这个产品将需要很多钱。我们可以讨论剩下的事情,但如果我们做了这么多,而你推出了你的产品,然后就这样做了,那看起来它会是一个有价值的产品。”
I asked Gary, “Now what? We have all these other users with other things they want to do—do you want to talk about them? You can see that if we keep talking we’ll need a bigger room. And, Gary, if you do all this stuff, it will take a lot of money to build this product. We could talk about the rest of this stuff, but if we built this much and you launched your product and just did this, that looks like it’d be a valuable product.”
加里同意了,他说:“我要到此为止了。”
Gary agreed, and he said, “I’m going to stop there.”
这个故事的悲伤部分是我问加里,“到目前为止你已经构建了很多软件,但是你构建的软件中有多少是在我们创建的这张地图上的?”
The sad part of this story is that I asked Gary, “You’ve been building a lot of software so far, but how much of the software you’ve built is on this map we’ve created?”
“几乎没有,”加里回答说,“因为当我列出清单并确定优先顺序时,我有点假设我们需要从其他地方开始。我当时在想这件事的整个宏伟愿景,我要花很多年才能达到的愿景,现在我们已经讨论过了,我根本不会从那里开始。”
“Nearly none of it,” Gary replied, “because when I built a list and prioritized things, I sort of assumed we needed to start somewhere else. I was thinking about the whole big vision of this thing, the vision that would have taken me years to reach, and now that we’ve had this discussion I wouldn’t have started there at all.”
故事地图是关于进行良好的老式对话,然后以地图的形式组织它。大多数人看的部分是地图——从左到右的形状,以及人们讲述一个大故事所采取的步骤。从上到下是关于细节的。但是构成产品框架并提供更多上下文的关键部分通常挂在地图上方和周围。它们是产品的目标,以及有关其客户和用户的信息。如果您将地图挂在墙上,您会发现在地图周围添加用户界面 (UI) 草图和其他注释是个好主意。
Story mapping is all about having a good old-fashioned conversation and then organizing it in the form of a map. The part that most people look at is the map—that left-to-right shape with the steps people take to tell a big story. The top to bottom is about the details. But the critical parts that frame the product and give more context are often hung above and around the map. They’re the product’s goals, and information about its customers and users. If you keep a map on the wall, you’ll find it’s good idea to add user interface (UI) sketches and other notes around the map.
在仅仅一天的合作中,加里和我就他想要构建的产品建立了共同的理解。但是我们头顶上形成了乌云,我们知道这一点。我们写的每张卡片中都有很多细节和更多讨论。而且,对于 Gary 来说,所有这些细节和所有这些讨论都等同于他需要花钱来构建软件——他没有的钱。他学到了关于软件开发的一个基本真理:要构建的东西总是比你有时间的多。
In just a day working together, Gary and I built shared understanding around the product he wanted to build. But there was a storm cloud forming above our heads, and we knew it. Inside each of those cards we wrote were lots of details and lots more discussions. And, for Gary, all those details and all those discussions equated to money he would need to spend to build software—money he didn’t have. He’d learned one of the fundamental truths about software development: there’s always more to build than you’ll have time for.
现在,Gary 对使用他的产品的人做出了很多其他重大假设,如果他们真的想要,或者真的可以按照他的设想使用它。但是,眼下,那些事情并不是他最关心的。他需要更加努力地工作,将他的产品创意最小化为首先可行的东西。
Now, there are a lot of other big assumptions Gary was making about the people who’d use his product, and if they really wanted to, or really could use it as he envisioned. But, right now, those things weren’t his biggest concern. He needed to work harder to minimize his product idea to something that was feasible first.
加里的故事最终有了一个圆满的结局。但在下一章中,我将讲述另一个组织的故事,该组织了解到自己要建设的东西太多了,以及它如何使用地图找到可行的解决方案。
Gary’s story eventually has a very happy ending. But in the next chapter I’ll tell the story of another organization that learned it had way too much to build, and how it used a map to find a viable solution.
[ 4 ]照片由 Piutus 拍摄,可在Flickr上找到,并已获得知识共享署名许可。
[4] Photo taken by Piutus, found on Flickr and licensed under the Creative Common Attribution license.
[ 5 ]在Business Insider文章“这家伙如何在没有任何 VC 资金的情况下启动数百万美元的初创公司”中阅读有关 Gary 的信息。
[5] Read about Gary in the Business Insider article “How This Guy Launched A Multi-Million Dollar Startup Without Any VC Money”.
总有比你拥有的人力、时间或金钱更多的东西需要建造。总是。
There’s always more to build than you have people, time, or money for. Always.
说“总是”和“从不”这样的绝对词总是让我惹上麻烦。但是对于上面的陈述,老实说,尽管我没有科学数据来支持这一点,但我真的不记得有什么情况是不正确的。从来没有人来找我说,“我们被要求添加这个新功能,很高兴我们有比我们需要的更多的时间。”
Speaking in absolutes like “always” and “never” always gets me in trouble. But with the statement above, I honestly can’t recall a situation where it wasn’t true although I have no sciencey data to back this up. No one has ever once come to me saying, “We were asked to add this new feature, and happily we had lots more time than we needed.”
但使用故事地图最酷的事情之一是,它为您和其他合作者提供了一个空间来思考备选方案,并找到一种在您拥有的时间内取得出色成果的方法。
But one of the coolest things about using a story map is that it gives you and other collaborators a space to think through alternatives and to find a way to get a great outcome in the time that you have.
喝杯咖啡,坐在椅子上。是时候讲故事了。
Grab a cup of coffee and settle into your chair. It’s time for a story.
这个故事是关于我在全球最大媒体Globo.com的朋友们的公司在巴西。Globo.com 拥有电视台和广播电台,制作电视电影和原创节目,并出版报纸。它是巴西的媒体巨头,也是世界上最大的葡萄牙语媒体公司。
This story is about my friends at Globo.com, the largest media company in Brazil. Globo.com owns television and radio stations, produces made-for-TV movies and original programming, and publishes newspapers. It is a media monster in Brazil, and the largest Portuguese-language media company in the world.
Globo.com 比地球上的大多数组织更清楚什么是不可更改的最后期限。例如,它制作了一个很酷的梦幻足球游戏版本,每年都会为世界杯足球赛——地球上大多数人都称之为足球的运动——进行修改和改进。如果 Globo.com 迟迟不能开发该游戏,它就没有更改发布日期的奢侈。为什么不?因为世界其他地方不会重新安排世界杯。Globo.com 将为巴西将于 2016 年举办的奥运会制作专题报道和内容,我可以向您保证它会按时完成——它必须做到。它将为众多新电视节目和真人秀节目制作专题和内容。如果 Globo.com 迟到了,这些事情都无法重新安排。Globo.com 必须始终按时完成。而且,由于这是其业务的现实,Globo.com 擅长于此。这并不是因为该公司比其他所有人都快——当然,它很快,但没那么快。这是因为少做事是明智的。
Globo.com knows better than most organizations on the planet what unmovable deadlines really are. For example, it produces a cool version of a fantasy football game that’s revised and improved every year for World Cup soccer—the sport that most of the planet refers to as football. If Globo.com is late with development of that game, it doesn’t have the luxury of changing the release date. Why not? Because the rest of the world won’t reschedule the World Cup. Globo.com will produce features and content for the Olympics games that Brazil will host in 2016, and I can guarantee you that it’ll get it done in time—it has to. And it’ll produce features and content for the release of numerous new television programs and reality TV shows. None of these things can be rescheduled if Globo.com is late. Globo.com must always finish on time. And, since that’s the reality of its business, Globo.com is good at it. That’s not because the company is faster than everyone else—sure, it’s fast, but it’s not that fast. It’s because it’s smart about doing less.
看看这个:
Take a look at this:
这只是来自 Globo.com 三个不同小组的八个团队的领导共同构建的一张相当大的地图的一部分。来自体育、新闻和娱乐的团队一起构建了这个,以思考他们需要做的工作来重建、改造和翻新他们的底层内容管理系统。这是驱动所有这些新闻网站、体育网站、肥皂剧网站、帮助宣传和招募真人秀节目的功能的系统,等等。这个庞大的系统需要能够处理大量的视频源、实时比分和选举结果、照片、突发新闻报道等等。它有很多事情要做,并且需要看起来很好。
That’s just a portion of a pretty big map built by leaders of eight teams from three different groups at Globo.com working together. The teams from Sports, News, and Entertainment built this together to think through the work they needed to do to rebuild, revamp, and renovate their underlying content management system. This is the system that drives all those news websites, sports websites, soap opera websites, features that help publicize and recruit people for reality TV shows, and much, much more. This massive system needs to be able to handle large quantities of video feeds, real-time scores and election results, photographs, fast-breaking news stories, and much more. It has a lot to do, and it needs to look good doing it.
当我在他们制作这张地图的那天到达 Globo.com 办公室时,一起工作的团队即将陷入扁平积压陷阱。各个团队已经准备了各自的优先级积压工作。已经很清楚有大量工作要做,而且每个团队都相互依赖。例如,要推出一个好新闻网站,不仅需要新闻团队,还需要构建基础组件的所有其他团队,让新闻网站使用照片、视频、实时数据和许多其他内容。
When I arrived at the Globo.com offices the day they built this map, the teams working together were about to fall into the flat backlog trap. Individual teams had prepared their respective prioritized backlogs. It was already clear there was a huge amount of work to do, and each team depended on the other. For instance, to get a good news site out would need not just the news team, but also all the other teams that built the foundational components that let the news website use photos, videos, real-time data, and lots of other things.
我和他们坐下来,提醒他们一些他们已经知道的事情:“我知道你们是不同的团队,因为你们专注于不同的领域,但这是对一个内容管理系统的重大修订。你们必须一起释放。在您可以一起看到所有内容之前,您无法计划发布。你必须想象所有这些依赖关系。” 他们同意并迅速开始工作,将他们各自的积压工作重新组织成一张地图。在几个小时内,他们使用便利贴在墙上制作了一张地图,讲述了他们的内容管理系统的故事。
I sat down with them and reminded them of something they already knew: “I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.” They agreed and quickly went to work reorganizing their individual backlogs into a map. Within a few hours they built a map on the wall using sticky notes that told the story of their content management system.
当团队成员一起构建地图时,我不在房间里。但是当我当天晚些时候回来时,我对他们建造它的速度感到惊讶。他们对自己很满意,并且完全有权利这样做。他们理解了几个复杂的积压工作,将它们组织成一个连贯的产品故事。现在每个团队都可以看到自己的工作在大局中的位置。
I wasn’t in the room while team members worked together to build the map. But when I returned later in the day, I was amazed at how quickly they’d built it. They were pleased with themselves, and had every right to be. They’d made sense of several complex backlogs, organizing them into one coherent product story. And now each team could see where its work fit into the big picture.
映射跨多个团队的产品发布以可视化依赖关系。
Map for a product release across multiple teams to visualize dependencies.
当我与构建故事地图的人交谈时,他们会告诉我,“每次我们这样做都会发现漏洞。我们发现了一些我们认为应该由另一个团队负责但它不知道的事情。我们在我们忘记谈论的重要功能之间找到了必要的东西。” 通过一起映射,Globo.com 找到了其中的一些。
When I talk with people who have built story maps, they’ll tell me, “Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know. We find the necessary stuff in between the big important features that we’d forgot to talk about.” By mapping together, Globo.com found some of that.
在您设想了整个产品或功能之后,开始玩“What-About”游戏就容易多了。这就是我们开始问的地方,“如果出现问题怎么办?” 或者“那些其他用户呢?” 玩 What-About 解决您的任何问题,并在地图主体上添加便利贴以获取您需要的功能创意,以便在您的软件中解决这些问题。在第 1 章中,加里玩 What-About 来考虑选择和备选方案。当您与其他团队一起这样做时,您会发现他们非常善于发现不同系统相互连接时可能出现的问题。
After you’ve envisioned the whole product or feature, it’s easier to start to play the “What-About” game. That’s where we start asking, “What about when this goes wrong?” Or “What about these other users?” Play What-About with any concern you have, and add stickies to the body of the map for feature ideas you’ll need in order to address these things in your software. In Chapter 1, Gary played What-About to consider options and alternatives. When you do this with other teams, you’ll find they’re terrific at spotting problems that might arise where different systems connect to each other.
人们有时对故事地图提出的批评之一是,每次他们坐下来创建故事地图时,他们最终都会得到太多。但我相信,我们现在只是找到了以后会伤害我们的东西,这是一件好事。
One of the criticisms people sometimes make about story mapping is that every time they sit down and create story maps, they end up with way too much. But it’s my belief that we’re just finding the stuff now that would have bitten us later on, and that’s a good thing.
在老式的软件开发方法中,当我们稍后发现新东西时——在我们已经估计交付时间并承诺交付日期之后——我们称这种新东西为范围蔓延。我个人认为范围不会蔓延;理解增长。当人们构建其中一个故事地图时,他们会发现自己的理解存在漏洞。
In the old-school approach to software development, when we’d find that new stuff later on—after we’d already estimated delivery time and committed to a delivery date—we’d call that new stuff scope creep. I personally believe that scope doesn’t creep; understanding grows. And what happens when people build one of these story maps is that they find the holes in their understanding.
范围不会蔓延;理解增长。
Scope doesn’t creep; understanding grows.
当我离开 Globo.com 的内容管理团队时,一切都很棒——相互理解,团队知道该做什么。然而,当我几天后回来与他们核实时,他们再次陷入困境,因为他们意识到有太多的工作要做,可能需要一年多的时间才能完成地图上的所有内容。当然,正如精明的读者所理解的那样,当软件开发人员说要花一年时间才能完成某件事时,他们实际上是指两年。这并不是因为他们不称职,或者他们的日程安排受到挑战,只是估计时间来做我们以前从未做过的事情是我们很不擅长的事情。而且,从本质上讲,我们通常是乐观的动物。
When I left the content management teams at Globo.com, everything was wonderful—understanding was rampant and the teams knew what to do. However, when I came back to check in with them a couple days later, they were struggling again because they realized that there was so much work to be done, that it would likely take more than a year to accomplish everything on the map. And, of course, as savvy readers can appreciate, when software developers say it’s going to take a year to get something done, they really mean two years. It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.
他们对我说:“太多了。我们在这里有很多事情要做,这需要很长时间。”
They said to me, “There’s way too much. We have a lot to do here and it’s going to take a long time.”
“你必须做这一切吗?” 我问。
“Do you have to do it all?” I asked.
他们当然回答说,“是的,因为它都是一个大型内容管理系统的一部分。”
They, of course, replied, “Yes, because it’s all part of one, big content management system.”
“但是这里的项目不会运行那么久,”我回答道。“我认识你们的 CEO,他希望更快地看到结果——对吧?”
“But projects don’t run that long around here,” I replied. “I know your CEO and he’s going to want to see results much faster—right?”
“是的,”他们证实,“他希望在几个月后即将举行的巴西大选中及时看到一些东西!”
“Yes,” they confirmed, “he wants to see something live in time for the upcoming Brazilian election in a few months!”
“你需要所有这些来为选举上线吗?” 我问。
“Do you need all of this to go live for the election?” I asked.
我一问这个问题,就看到灯泡亮了。当然,他们并不需要一切。到目前为止,他们一直专注于确定序列和依赖性,假设他们需要构建所有内容。他们做到了,但这实际上是时间问题。他们改变了想法,将重点放在结果上。
As soon as I asked the question, I could see light bulbs click on. Of course they didn’t need everything. Up ‘til now, they’d been focused on identifying sequence and dependency assuming they’d need to build everything. They did, but it was really a question of when. They shifted their thinking to focus on outcomes.
专注于您希望系统外部发生的事情,以决定系统内部的情况。
Focus on what you hope will happen outside the system to make decisions about what’s inside the system.
Globo.com 专注于巴西选举。这些团队特别考虑了在整个选举期间以更新、更性感的互动内容风格成功打动访客、广告商和 Globo 母媒体公司的伟大成果。如果他们那样做,他们就会赢。
Globo.com focused on Brazilian elections. The teams thought specifically about the great outcome of successfully impressing visitors, advertisers, and Globo’s parent media company with newer, sexier styles of interactive content throughout the election. If they did that, they’d have a win.
这不是他们第一次面对不可能的交货日期。他们考虑了一下,意识到他们肯定需要在新闻网站上线,并且可能需要一些其他支持它的东西,因为这是访问者和其他人会去监督巴西选举的地方。专注于新闻网站意味着关注创新的方式来更快地显示实时选举数据和突发新闻。当然,还有一个更新的、最新的视觉设计覆盖了一切。
This wasn’t their first time facing down an impossible delivery date. They thought about it for a bit, and realized that they definitely needed to go live with the news website, and potentially some other things that supported it because that’s where visitors and others would go to monitor Brazilian elections. Focusing on the news website meant paying attention to innovative ways to show real-time election data and breaking news stories faster. And, of course, there was a newer, up-to-date visual design overlaying everything.
团队抓起一卷蓝色画家的胶带,在地图上从左到右拉伸线条以制作水平切片。然后,他们开始上下移动卡片,在蓝线上方和下方移动卡片,以指定哪些事情需要在第一个切片中完成,哪些可以稍后完成。
The teams grabbed a roll of blue painter’s tape and stretched lines across the map left to right to make horizontal slices. They then went to work moving cards up and down, above and below the blue lines to designate which things needed to be done in the first slice, and which could be done later.
思考过程有点像这样:如果我们为巴西大选直播,巴西的很多人都会看到这件事。它会溅起水花降落。它会影响我们的这些网站,我们会看起来很好。这片中的所有内容都是用户在软件发布后需要做的事情,这样他们才能引起轰动。
The thought process worked a bit like this: If we go live for the Brazilian elections, a lot of people in Brazil will see this thing. It’s going to land with a splash. It’s going to affect these websites of ours and we’ll look good. Everything in this slice is what users will need to be able to do after the software is released so they can make that splash.
关注结果——用户需要做什么,看看系统什么时候出来——并分割出能给你带来这些结果的版本。
Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.
该地图包含可以改进所有 Globo.com 网络属性的创新内容。但要完成所有这些工作确实需要很长时间。抓住选举创造的市场窗口将是一个不容错过的大好机会。专注于此有助于 Globo 确定第一个版本。
The map contained innovative things that would improve all Globo.com’s web properties. But it really was going to take a long time to get all of it done. Hitting the market window that the elections created would be too big an opportunity to miss. Focusing on that helped Globo identify the first release.
然后,团队开始思考下一个版本应该锚定哪些类型的 Web 属性和市场事件。他们在每个切片的左侧张贴便签,用几个词描述他们对每个发布切片的意图——他们的目标结果。然后他们继续将卡片上下移动到正确的切片中。
The teams then went to work thinking about what kinds of web properties and market events should anchor the next releases. They posted sticky notes to the left of each slice with a few words describing their intention for each release slice—their target outcomes. Then they continued to move cards up and down into their correct slices.
最终,他们有了一个增量发布策略,让他们能够处理随着时间的推移更换整个内容管理系统所需的所有工作,并且以这样一种方式让他们看到每次发布都带来真正的好处。如果他们向下阅读地图的左边缘,他们会得到一个命名版本列表,每个版本都有特定的目标结果。这是一个发布路线图。
In the end, they had an incremental release strategy that let them tackle all the work they needed to do to replace the whole content management system over time, and in such a way that they saw real benefit with each release. If they read down the left edge of the map, they had a list of named releases, each with specific target outcomes. This is a release roadmap.
请注意列表不是一堆功能。这是一份现实世界的好处清单——因为请记住,您的工作不是构建软件,而是改变世界。困难的部分是选择你想为哪些人改变世界,以及如何改变世界。
Notice how the list isn’t a bunch of features. It’s a list of real-world benefits—because, remember, your job isn’t to build software, it’s to change the world. The hard part is choosing which people you want to change the world for, and how.
关注特定的目标结果是确定开发工作优先级的秘诀。
Focusing on specific target outcomes is the secret to prioritizing development work.
反之亦然。也就是说,如果您不知道您的目标结果是什么——您想要获得的具体收益——那么几乎不可能确定优先级。
And the opposite is true as well; that is, if you don’t know what your target outcomes are—the specific benefits you’re trying to get—then prioritization is close to impossible.
还要注意 Globo 团队是如何从更换整个内容管理系统的大目标开始的。替换内容管理系统是输出,他们要运送的东西。这样做会带来很多积极的结果。分解真正大块输出的秘诀是专注于更小的、特定的结果。
Notice also how the Globo teams started with a big goal of replacing their entire content management system. Replacing the content management system is the output, the stuff they were going to deliver. Doing that would result in lots of positive outcomes. The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome.
请记住:结果的背后是从事特定活动的特定人员的特定行为变化。通过关注即将举行的巴西选举,Globo 选择关注关注新闻的人,尤其是那些寻找最新选举细节的人。但是,在将重点放在这些人身上时,它忽略了肥皂剧爱好者、体育爱好者和许多其他类型的用户。那些其他人将不得不对当前站点感到满意一段时间。记住,你不可能总是取悦所有人。
Remember: behind outcomes are specific behavior changes for specific people engaged in specific activities. By focusing on the upcoming Brazilian elections, Globo chose to focus on the people who follow the news, especially those looking for up-to-the-minute election details. But, in placing its focus on those people, it left out soap opera lovers, sports lovers, and lots of other types of users. Those other people would have to be satisfied with the current site for a while longer. Remember, you can’t please everyone all the time.
我可能很容易被打动,但切片是将软件创意组织成故事地图最酷的事情之一。
I may be easily impressed, but slicing is one of the coolest things about organizing software ideas into a story map.
很多时候,我和与我共事的团队都将我们关于完美产品的所有想法都放在了一张地图上,但如果我们创造这一切,我们将面临的工作量不知所措。这一切似乎都很重要。但随后我们退后一步,思考将使用我们产品的特定人群,以及他们需要完成什么才能取得成功。我们将其提炼成一两句话。然后我们切掉所有我们不需要的东西,我们对我们可行的解决方案实际上有多小感到震惊。这很神奇。
Many times I, and the teams I’ve worked with, have placed all our ideas about the perfect product into a map and been overwhelmed by the amount of work we’d have if we created it all. It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful. We distill that into a sentence or two. Then we carve away everything we don’t need, and we’re shocked at how small our viable solution really is. It’s magic.
第 1 章的Gary继续对他的产品做类似的事情。他最终将注意力集中在乐队经理、歌迷和 Mimi 的内部管理员身上——因为你必须让网站保持运行。加里选择将场地经理和制作音乐家排除在外。最后,他意识到,通过只关注那几个人和推广活动,他最终得到了一个很棒的电子邮件推广平台。所以,对于今天的 Mimi 用户来说,这就是您所知道的体验。
Gary from Chapter 1 went on to do something similar with his product. He eventually narrowed focus to the band manager, the fan, and Mimi’s internal administrator—because you’ve got to keep the site running. Gary chose to leave out venue managers and production musicians. In the end, what he realized is that by focusing on just those few people and the activity of promoting, he ended up with a great email promotion platform. So, for those of you who are Mimi users today, that’s the experience you know.
将我们的思维外化到一张可见的大地图中,可以使所有这些步骤变得更容易。它使许多人协作完成它成为可能。
Externalizing our thinking in a big visible map makes all these steps easier. It makes it possible for lots of people to collaborate to accomplish it.
有一个术语在软件开发行业中流行了很长时间:最小可行产品,或简称为 MVP。Frank Robinson 因最初创造了MVP一词而受到赞誉,但如今 Eric Ries 和 Steve Blank 的定义占主导地位。尽管有很多聪明人试图定义这个术语,但每个人似乎仍然感到困惑——包括我。我遇到的每个使用该术语的组织都略有不同。即使是同一个组织中的人和同一个对话也常常意味着不同的事情。
There’s a term that’s been kicking around in the software development industry for a long time: minimum viable product, or simply MVP. Frank Robinson is credited with originally coining the term MVP, but these days definitions from Eric Ries and Steve Blank dominate. In spite of multiple smart people trying to define the term, everyone still seems confused—including me. Every organization I run into that uses that term means something slightly different. Even people in the same organization and the same conversation often mean different things.
与字典中的大多数单词一样,它具有多重含义。我将为该术语给出三个定义:一个不好的定义和两个好的定义。
Like most words in the dictionary, it has multiple meanings. I’m going to give you three definitions for the term: a bad one, and two good ones.
这是坏的:
Here’s the bad one:
最小可行产品并不是你可能发布的最糟糕的产品。
Minimum viable product is not the crappiest product you could possibly release.
并且 MVP不是您的用户可以使用的产品,但只有在最简单的情况下,并且只有当他们有很高的痛苦阈值时才可以使用。我经常看到组织通过有人可以使用该产品的论点来合理化他们糟糕的产品决策,而当每个相关人员都清楚他们可能不会选择使用该产品时。
And the MVP isn’t the product that your users could use, but only in the simplest of circumstances, and only if they had a high threshold for pain. I commonly see organizations rationalizing their bad product decisions with the argument that someone could use the product, when it’s clear to everyone involved that they probably wouldn’t choose to.
如果 Globo.com 使用这个定义来分割它的第一个版本,它会产生负面结果。没有人会留下深刻印象。品牌会受到伤害,公司的境况会比什么都不发布还要糟糕。
If Globo.com had used this definition for slicing out its first release, it would have had a negative outcome. No one would have been impressed. The brand would have been hurt, and the company would have been worse off than if it had released nothing at all.
当我们在谈论活的有机体时使用术语viable时,它意味着有机体可以在世界上独立生存而不会死亡。当我们谈论软件时,我们指的是同一件事。
When we use the term viable when talking about a living organism, it means that an organism can survive in the world on its own without dying. And when we talk about software, we mean the same thing.
最小可行产品是成功实现预期结果的最小产品版本。
The minimum viable product is the smallest product release that successfully achieves its desired outcomes.
我最喜欢这个定义。最小值是一个主观术语。因此,请具体说明它的主观对象是谁——因为不是你。具体说明您的客户和用户是谁,以及他们需要完成什么。对他们来说最起码的是什么?我向你保证,这会对谈话有很大帮助。这仍然是一场艰难的谈话。但另一种方法是“HiPPO”方法——“最高收入者的意见”。那个更糟糕。
I like this definition best. Minimum is a subjective term. So be specific about who it’s subjective to—because it’s not you. Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them? I promise you, it’ll help the conversation hugely. It’s still a tough conversation. But the alternative is the “HiPPO” method—the “highest paid person’s opinion.” That one sucks worse.
这些天我更喜欢的术语是minimum viable solution。我与组织合作的大部分事情都不是完整的新产品。它们是新特性或功能,或者是对现有特性的改进。所以术语解决方案似乎更有意义。所以让我修改一下我的定义:
The term I prefer these days is minimum viable solution. Most of the things I work with organizations on aren’t whole, new products. They’re new features or capabilities, or improvements on features already out there. So the term solution seems to make more sense. So let me revise my definition:
最小可行解决方案是成功实现预期结果的最小解决方案版本。
The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.
困难的部分来了……
Here comes the hard part…
我们只是在猜测。
We’re just guessing.
当我们切出一堆软件功能并将其称为最小可行解决方案时,我们真的不知道它是否是。
When we slice out a bunch of software functionality and call it a minimum viable solution, we don’t really know if it is.
结果的问题在于,在事情出现之前,你无法真正观察到它们。当你切出一个版本时,你不得不假设会发生什么。您可能不得不猜测哪些客户会购买您的产品,哪些用户会选择使用它,如果他们可以使用它,以及在您有的时间内构建什么是可行的。你不得不猜测有多少会让他们开心。这是很多猜测。
The problem with outcomes is that you can’t really observe them until things come out. When you slice out a release, you’re forced to hypothesize what will happen. You might have to guess about what customers will buy your product, what users will choose to use it, if they can use it, and what’s feasible to build in the time you have. You’re forced to guess at how much will make them happy. That’s a lot of guessing.
这很糟糕,因为如果你猜得太低,好吧,那还不到最小值,你就失败了。如果你猜得太高,很多人都会这样做来对冲他们的赌注,那么你就花了太多钱,而且常常冒着根本无法完成事情的风险。最糟糕的是,你可能完全错了,你运送的东西再多也无足轻重。
This sucks, because if you guess too low, well, that’s less than minimal, and you’ve failed. If you guess too high, which many people do to hedge their bets, then you’ve spent too much money and often risk not getting things done at all. And worst of all, you could be just dead wrong, and no amount of what you ship will matter at all.
难怪“你可能发布的最糟糕的产品”的定义仍然盛行。因为那是我们不需要猜测的。
It’s no wonder that the “crappiest product you could possibly release” definition still thrives. Because that’s the one we don’t need to guess about.
我知道你们中的一些人可能在最近几章中感到越来越紧张。您可能会想,Jeff 忽略了最重要的事情!你可能是对的。你最重要的一些事情在故事和故事地图对话中可以讨论的是:
I know that some of you may have been feeling progressively twitchy over the last couple of chapters. You may have thought to yourself, Jeff’s overlooking the most important thing of all! And you might be right. Some of the most important things you can discuss during story and story map conversations are:
这引出了我对 MVP 的第三个定义,正如 Eric Ries 在他的《精益创业》(皇冠企业)一书中所推广的那样。像我们大多数人一样,埃里克通过惨痛的教训了解到,我们只是在猜测。埃里克在一家公司工作,该公司发布了一种它认为可行的产品,但这是错误的。他明智地改变了策略,将重点放在学习上——专注于验证公司在第一个 MVP 版本中所做的所有假设。埃里克提出了一个重要的观点,即我们需要创建更小的实验、原型来检验我们关于什么是最小和可行的假设。如果你采用埃里克的思维方式,你应该这样做,你的第一个产品真的应该是一个实验——然后是一个实验,然后是一个实验,直到你真正证明你得到了正确的产品。
This leads me to my third definition of MVP, as popularized by Eric Ries in his book The Lean Startup (Crown Business). Eric learned the hard way, as most of us do, that we’re just guessing. Eric worked for a company that released a product that it thought was viable, but it was wrong. Intelligently, he changed his strategy to focus on learning—to focus on validating all those assumptions the company had made in its first MVP release. Eric makes the important point that we need to create smaller experiments, prototypes that test our hypothesis about what’s minimal and viable. And if you adopt Eric’s way of thinking, which you should, your first product should really be an experiment—and the one after that, and the one after that, until you really prove that you’ve got the right product.
一个最小的可行产品也是你可以创造或做的最小的事情来证明或反驳一个假设。
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
虽然 Globo.com 的人们能够制定减少建设的计划非常酷,但他们并不是在自欺欺人。他们知道还有很多东西需要学习来证明他们的假设是正确的。他们和其他所有人都需要从这里制定计划以了解更多信息。这就是我们将在下一章中讲述我们的故事的地方。
While it was pretty cool that the folks at Globo.com were able to create a plan to build less, they weren’t fooling themselves. They knew there was lots left to learn to prove their assumptions were good. From here they and everyone else need to create a plan to learn more. And that’s where we’ll pick up our story in the next chapter.
这是我的朋友埃里克,站在他的团队房间里他的积压工作和任务板前。他是一名产品负责人,与他的团队一起努力打造一款成功的产品,但现在并非如此。不过,埃里克并不担心。他有一个使他的产品成功的策略。到目前为止它正在工作。
This is my friend Eric, standing in front of his backlog and task board in his team room. He’s a product owner working hard with his team to build a successful product, but right now it’s not. That doesn’t worry Eric, though. He has a strategy for making his product successful. And so far it’s working.
Eric 在一家名为 Liquidnet 的公司工作。Liquidnet 是面向机构投资者的全球交易网络。早在埃里克站在照片中的董事会面前之前,他公司的某个人就确定了一组 Liquidnet 可以更好地服务的客户,以及一些如何做到这一点的想法。Eric 是采纳这些想法并付诸实施的团队的一员。这就是产品所有者所做的。如果你认为他们总是按照自己的伟大想法行事,那你就错了。成为产品负责人最困难的部分之一是拥有他人的想法并帮助使其成功,或者证明它不太可能成功。最好的产品负责人,如埃里克,帮助他们的整个团队获得产品的所有权。
Eric works for a company called Liquidnet. Liquidnet is a global trading network for institutional investors. Long before Eric came to stand in front of the board in the picture, someone at his company identified a group of customers Liquidnet could serve better, along with a few ideas of how to do that. Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.
Eric 并没有通过积压用户故事来开始他的工作。他从某人的伟大想法开始,并将其视为公司的机会——因为它确实是。他与公司的领导层进行了交谈,以了解更多信息。他们讨论:
Eric didn’t start his work by building a backlog of user stories. He started with the big idea someone had, and treated it like an opportunity for his company—because it was. He had conversations with leadership in his company to understand more. They discussed:
Eric 需要先与组织中的其他人建立共识,然后才能抓住机会。他知道在接下来的几个月里他需要多次讲述这个产品的故事,所以他最好现在就开始做大事。
Eric needed to build shared understanding with others in his organization before he could take ownership of the opportunity. He knew he was going to need to tell the story of this product many times over the coming months, so he’d better get the big stuff right now.
您的第一个故事讨论是为了构建机会。
Your first story discussion is for framing the opportunity.
埃里克相信领导的直觉,但他知道这个伟大的想法只是一个假设。他知道确保想法成功的唯一方法是当他们真正看到它成功时。
Eric trusts his leadership’s intuition, but he knows that this big idea is a hypothesis. He knows the only way to be sure the idea will succeed is when they actually see it succeed.
他首先花时间直接与客户和用户交谈,以真正了解他们。在此过程中,他确认确实有客户遇到了问题,而且他们确实有兴趣购买解决方案。埃里克与可能使用该产品的人交谈。他们没有今天的产品,而且只有很差的解决方法来解决新产品创意可以解决的问题。
He first spent time talking to customers and users directly to really learn about them. Along the way he validated that there really were customers who had the problem, and they really were interested in buying a solution. Eric talked to the people who’d likely use the product. They didn’t have the product today, and had only poor workarounds to address the problems the new product idea would solve.
验证您正在解决的问题确实存在。
Validate that the problems you’re solving really exist.
在 Eric 与客户和用户交谈的同时,他一直在建立一个他认为适合试用他的新软件的人选。一些公司将这些人称为客户开发伙伴。跟踪这个细节,因为它会在故事的后面出现。
While Eric’s been talking with customers and users, he’s been building up a pool of people he thinks are good candidates to try his new software. Some companies refer to these people as customer development partners. Keep track of this detail, because it’s going to come up later in the story.
实际上,在这个阶段,不仅仅是埃里克。Eric 与一小群其他人一起工作,他们花了很多时间与客户交谈,在这样做的过程中,他发现解决问题并不那么容易——而且还有其他问题需要首先解决。你要带走的重要一点是,他们学得越多,原来的机会就改变得越多——最终改变了很多。幸运的是,他们并没有按照要求去做。那不会为他们的客户或他们的组织服务。
Actually, during this stage, it wasn’t just Eric. Eric was working with a small team of others who spent lots of time talking to their customers, and, in doing so, found that solving the problem wasn’t so easy—and that there were other problems that needed to be solved first. The important thing for you to take away is that the more they learned, the more the original opportunity was changed—eventually, a lot. It’s lucky they didn’t just get to work building what they were told to. That wouldn’t have served their customers or their organization.
到目前为止,埃里克和他的团队在与客户交谈后,对他们可以构建用户可以使用的解决方案类型有了具体的想法,并通过这样做获得他们的雇主想要的好处。现在,埃里克和他的团队可以在这里“全力以赴”——他们可以赌上一切。他们本可以积压一些故事来描述他们的解决方案,然后组建一个团队来构建它。因为他们是聪明人,所以他们会使用故事地图从大创意转移到要构建的具体部分。但是,因为他们真的很聪明,所以他们此时要做的最后一件事就是构建软件。
By now Eric and his team, after talking to customers, had specific ideas for the type of solution they could build that users could use, and by doing so get the benefit their employers wanted. Now, here’s where Eric and his team could have gone “all in”—where they could have bet it all. They could have built a backlog of stories that described their solution and set a team to work building it. Because they’re smart people, they’d have used a story map to move from the big idea to the specific parts to build. But, because they’re really smart, the last thing they’re going to do at this point is to build software.
正是在这里,埃里克开始担任该产品的所有者。他首先将他的解决方案设想为一堆简单的叙事故事——用户场景。然后他开始将这个想法设想为一个简单的线框草图。然后他创建了一个更高保真度的原型。这不是工作软件。这是一个简单的电子原型,使用 Axure 或 PowerPoint 等简单工具创建。
It’s around here that Eric began to act as the owner for this product. He moved to envision his solution first as a bunch of simple narrative stories—user scenarios. Then he moved to envisioning the idea as a simple wireframe sketch. And then he created a higher-fidelity prototype. This wasn’t working software. It was a simple electronic prototype, created with a simple tool like Axure, or maybe even PowerPoint.
所有这些都是 Eric 的学习步骤。他们帮助他设想他的解决方案。最终,他想将他的解决方案展示在用户面前,看看他们的想法。但他知道,在将其摆在他们面前之前,他首先需要确信它能解决他们的问题。
All of these are learning steps for Eric. They help him envision his solution. Ultimately, he wants to put his solution in front of his users to see what they think. But he knows he first needs to feel confident it solves their problems before he puts it in front of them.
草图和原型,以便您可以设想您的解决方案。
Sketch and prototype so you can envision your solution.
现在,我对你隐藏了一个重要的细节。Eric 实际上是一名交互设计师。他是那种习惯于与客户和用户共度时光,并习惯于构建这些简单原型的设计师。但是,对于这个新产品,他也是产品负责人——对产品的成功负最终责任的人。Eric 公司的其他产品负责人没有他的设计技能,他们非常明智地与设计师结对,以帮助采访用户和构想解决方案。
Now, I’ve hidden an important detail from you. Eric was actually an interaction designer. He’s the kind of designer who’s used to spending time with customers and users, and used to building these simple prototypes. But, for this new product, he’s also the product owner—the one ultimately responsible for the product’s success. There are other product owners in Eric’s company who don’t have his design skills, and they very sensibly pair with designers to help with both interviewing users and envisioning solutions.
Eric 最终确实将原型带回给了用户。我当时不在场,所以我不知道 Eric 到底发生了什么。但我遇到过很多次这种情况,而且我总是对我从真正使用我的解决方案的人那里学到的东西感到惊讶。我只能告诉你的是,为惊喜和坏消息做好准备。事实上,庆祝这个坏消息,因为你可能会在几个月后,在你构建软件之后收到同样的坏消息。那才是真正糟糕的时候。现在,进行更改的成本很低,您应该这样做。埃里克做到了。
Eric did eventually bring prototypes back to users. And I wasn’t there, so I don’t know what really happened for Eric. But I’ve been in these situation lots of times, and I’m always surprised about what I learn from the people who’ll really use my solution. All I can tell you is, be prepared for surprises and bad news. In fact, celebrate the bad news, because you could have received the same bad news months later, after you’d built the software. That’s when it really sucks. Right now, it’s cheap to make changes, and you should. And Eric did.
与用户一起制作原型并进行测试,以了解您的解决方案是否有价值和可用。
Prototype and test with users to learn whether your solution is valuable and usable.
在多次迭代他的解决方案并将其展示给客户后,Eric 确信他有一个非常好的解决方案创意。当然,现在他可以建立积压工作,并让他的开发团队着手将原型解决方案转变为真正可用的软件。但埃里克不会那样做。好吧,不完全是这样。这是一个比他愿意接受的更大的赌注。
After iterating his solution many times and showing it to his customers, Eric was confident he had a pretty good solution idea. Surely now he could get that backlog built, and get his team of developers to work turning that prototyped solution into real working software. But Eric’s not going to do that. Well, not exactly that. That’s a bigger bet than he’s willing to take.
Eric 对他认为可行的解决方案进行了原型设计。但他不确定它是否是最小的——因为他向人们展示了很多很酷的想法。如果你向人们展示所有很酷的想法,他们当然会喜欢它们。但埃里克知道他的工作是尽量减少他建造的数量并仍然让人们开心。他能拿走多少,仍然有可行的解决方案?
Eric has prototyped what he believes is a viable solution. But he’s not really sure if it’s minimal—because he showed people lots of cool ideas. And if you show people all the cool ideas, of course they’ll love them. But Eric knows his job is to minimize the amount he builds and still keep people happy. How much could he take away and still have a viable solution?
埃里克还知道一些有点令人不安的事情。他知道那些说他们喜欢它并使用它的人也只是在猜测。
Eric also knows something else that’s a bit disturbing. He knows the people who said they’d like it and use it are just guessing, too.
回想一下你自己买东西的时候。您可能看过产品。您可能已经看到销售人员演示了很酷的功能。您可能已经亲自试用了这些很酷的功能,并且您可以想象真正使用并喜欢该产品。但是当你购买产品并真正开始使用它时,你会发现这些很酷的功能并没有那么重要。真正重要的是您没有想到的功能。而且,最糟糕的是,也许你根本不需要那么多产品。好吧,也许这只是我在说的。但是我的车库里有很多东西我希望我从来没有买过。
Think back to when you’ve bought something yourself. You may have looked at the product. You might have watched a salesperson demonstrate the cool features. You may have tried out the cool features for yourself, and you could imagine really using and loving the product. But when you bought the product and actually started using it, you found the cool features didn’t matter so much. What really mattered were features you hadn’t thought about. And, worst of all, maybe you didn’t really need the product that much after all. OK, maybe it’s just me I’m talking about. But I’ve got lots of stuff in my garage that I wish I’d never bought.
回到埃里克。他知道他的客户和用户可以想象该产品会很好用,并且知道这一点让他有信心加大赌注。但真正的证据是那些人每天都选择使用它。这就是他正在寻找的真正结果——也是能让他的公司获得真正想要的利益的唯一结果。要了解这一点,需要的不仅仅是原型。
Back to Eric. He knows his customers and users can imagine the product would be great to use, and knowing that gives him the conviction to up his bet. But the real proof is when those people actually choose to use it every day. That’s the real outcome he’s looking for—and the only outcome that’ll get his company the benefit it really wants. And it’s going to take more than a prototype to learn that.
Now, here’s where Eric gets to show how smart he really is.
Eric 和他的团队确实开始着手构建软件。但他们的首要目标不是构建最小可行产品。实际上,它是为了构建一些不那么简单的东西——刚好足以让潜在用户可以用它做一些有用的事情。这是一款不会给太多人留下深刻印象的产品,他们甚至可能会讨厌它。这绝对不是您希望营销和销售人员推销的产品。事实上,您唯一希望看到该产品的人是有一天可能会使用该产品并且真诚地关心找到能够解决他们问题的产品的人。
Eric and his team actually do get to work building software. But their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal—just enough that potential users could do something useful with it. This is a product that wouldn’t impress too many people, and they might even hate it. It’s definitely not a product you’d want your marketing and sales people out there pitching. In fact, the only people you’d want to see this product are people who may one day use the product, and honestly care about finding a product that solves their problem.
恰好,埃里克身边就有一小群这样的人。这是他在了解和验证问题时与之合作的客户和用户。他们是他的发展伙伴。他们是对早期原型提供反馈的人。埃里克认为其中有一部分最能帮助他学习。他们是他会把这个低于最低限度——而且绝对不可行的——产品放在第一位的人。他希望他们能成为他的早期采用者。
It just so happens that Eric has a small group of people just like that. It’s the customers and users he worked with earlier when he was learning about and validating the problem. They’re his development partners. They’re the ones who gave feedback on early prototypes. And there’s a subset of them that Eric believes can best help him learn. They’re the ones he’ll put this first, less-than-minimum—and definitely not viable—product in front of. He hopes they’ll become his early adopters.
他就是这么做的。
And that’s what he did.
这是 Eric 指出他当前积压的一部分。拍摄这张照片时,他已经向他的开发合作伙伴发布了软件。在他这样做之后,他特意与他们交谈以获取他们的反馈。他的团队还建立了一些简单的指标,这样他们就可以衡量人们是否真的在使用该软件,以及他们具体在软件中做了什么。
This is Eric pointing out a slice of his current backlog. When this picture was taken, he’d already released software to his development partners. After he did, he made a point of talking to them to get their feedback. His team also built in some simple metrics so they could measure whether people were really using the software, and what they did in the software specifically.
埃里克知道人们很有礼貌。他们可能会说他们喜欢某个产品,但从不使用它。“使用它”是他想要的真正结果,礼貌对他没有帮助。Eric 也知道有些人要求很高。他们可能会列出产品存在的所有问题,或者抱怨错误,但指标可能会告诉我们他们每天都在使用它。这是一件好事,尽管他们一直在抱怨。抱怨也很好,因为它让埃里克知道他下一步应该改进的地方。
Eric knows that people are polite. They may say they like a product, but then never use it. The “using it” is the real outcome he wants, and polite isn’t helping him. Eric also knows some people are demanding. They may list all the problems the product has, or complain about bugs, but the metrics may be telling us that they use it every day anyway. And that’s a good thing, in spite of all their complaining. The complaining is good, too, because it gives Eric ideas about where his next improvements should be.
Eric 的积压工作被组织成一个故事地图,顶部用黄色便签纸表示主干。那些黄色的便利贴上有简短的动词短语,讲述了他的用户将在产品中做什么的大故事,但是是在高层次上。下面是所有细节——他们将做的具体事情以及真正使用该产品所需的事情。虽然他和他的团队处理的细节随着版本的不同而变化,但主干仍然非常一致。
Eric’s backlog is organized as a story map with the backbone in yellow stickies across the top. Those yellow stickies have short verb phrases on them that tell the big story of what his users will do in the product, but at a high level. Below it are all the details—the specific things they’ll do and need to really use the product. While the details he and his team work on change from release to release, the backbone stays pretty consistent.
磁带上方的顶部切片是埃里克和他的团队目前正在制作的切片。此版本需要 Eric 进行两次冲刺。他正在使用 Scrum 开发流程,其中他的冲刺是两周的时间盒。所以两次冲刺基本上相当于一个月。在其下方是沿着电路板运行的切片。下一个切片包含他们认为下一个版本可能是什么,等等。在每个切片的左边,就像 Globo.com 团队一样,挂了一张便签,上面有发布名称和一些关于他们想在此版本中学习的内容。除了最高版本,上面张贴了呆伯特卡通片。这是他们团队的一个内部笑话,我没有参与其中。
The top slice, above the tapeline, is the one Eric and his team are working on right now. This release will take Eric two sprints. He’s using a Scrum development process where his sprints are two-week time-boxes. So two sprints equate to basically a month. Below that are slices running down the board. The next slice contains what they think the next release might be, and so on. To the left of each slice, just as with the Globo.com team, hangs a sticky note with the release name and a few words about what they want to learn in this release. Except for the top release, which has a Dilbert cartoon posted over it. It’s an inside joke in their team that I wasn’t in on.
如果仔细观察,当前切片的顶部有点被清理掉了。我在它们原来所在的地方画了一些便利贴。但它们已经不存在了,因为那些在上面的东西是他的团队将首先建造的东西。当团队成员一起工作来计划他们的工作时,他们移除了那些便利贴并将它们放在任务板上,位于故事地图待办事项列表的右侧。该任务板显示了他们现在在这个冲刺中正在处理的故事,以及交付任务——开发人员和测试人员需要做的具体事情,以将故事中的想法转化为可用的软件。
If you look closely, the top of that current slice is sort of cleaned out. I’ve drawn in some sticky notes where they used to be. But they’re not there anymore because those things that were on the top are the first things his team will build. As the team members worked together to plan their work, they removed those sticky notes and placed them on a task board to the right of the story-mapped backlog. That task board shows the stories they’re working on now in this sprint, along with delivery task—the specific things that the developers and testers will need to do to turn the ideas in the story into working software.
埃里克的故事地图积压工作中有一个更妙的地方,也是证明他聪明的一个地方,就是最上面那部分的厚度。它的厚度是它下面的切片的两倍。当 Eric 和他的团队完成切片并交付时将它交给他们的开发合作伙伴——他们称之为测试版客户——他们会将便利贴从下面的切片中移上去。当他们这样做时,他们将对下一个分割版本进行更详细的讨论。他们会玩 What About 来发现问题并填写详细信息。他们将在下一个版本中讨论一些想法,这次讨论可能会导致他们将大想法分成两个或三个较小的想法。然后,他们将需要该切片中的垂直高度来确定优先级 - 以选择首先构建的内容。
One finer point of Eric’s story-mapped backlog, and one that proves he’s smart, is the thickness of that topmost slice. It’s twice as thick as the slices below it. When Eric and his team finish a slice and deliver it to their development partners—what they call their beta customers—they’ll move the sticky notes up from the slice below. When they do, they’ll have lots more detailed discussion about this next sliced-out release. They’ll play What About to find problems and fill in details. They’ll talk about some of the ideas in the next release, and this discussion may result in their splitting the big idea into two or three smaller ideas. And then, they’ll need the vertical height in that slice to prioritize—to make choices about what to build first.
看看他们有多聪明?
See how smart they are?
埃里克可能已经开始了整个过程,关于最小可行产品可能是什么的想法,但他故意构建了一些不最小的开始。然后他每个月都会增加一点。他从他的开发合作伙伴那里得到反馈——既有与他们交谈的主观内容,也有他从查看数据中获得的更客观的内容。
Eric may have started this whole process with an idea about what the minimum viable product might be, but he’s purposely built something less than minimal to start with. He’s then adding a bit more every month. He’s getting feedback from his development partners—both the subjective stuff from talking to them, and the more objective stuff he gets from looking at data.
他将保持这一策略,慢慢地发展和改进产品,直到他的开发合作伙伴真正开始定期使用该产品。事实上,埃里克希望他们成为向其他人推荐产品的人——真正的参考客户。当他们这样做时,他就知道自己找到了最低限度和可行的方法。那时产品可以安全地投放市场并疯狂销售。如果埃里克和他的团队以前曾尝试出售它,他们最终会遇到很多失望的客户——与他在整个过程中建立私人关系的那些人相比,他们要友好得多。
He’ll keep up this strategy, slowly growing and improving the product, until his development partners actually start using the product routinely. In fact, what Eric’s hoping for is that they become people who’d recommend the product to other people—real reference customers. When they do, that’s when he knows he’s found minimum and viable. And that’s when the product is safe to market and sell like crazy. If Eric and his team had tried to sell it before, they’d have ended up with lots of disappointed customers—people a lot less friendly than those with whom he built personal relationships throughout this process.
埃里克本可以做的是把他最后的、最好的原型,分解成所有的组成部分,然后开始一部分一部分地构建它。许多个月后,他会有一些东西要释放。如果他的大猜测是正确的,他就会知道。在这一点上你需要相信我,但它不会是——因为它很少是。
What Eric could have done is to take his last, best prototype, break it down into all its constituent parts, and start building it part by part. Many months later, he’d have had something to release. And he’d have learned then if his big guess was right. You’ll need to trust me on this, but it wouldn’t have been—because it rarely is.
这是我的朋友 Henrik Kniberg 制作的简单可视化。它很好地说明了一个失败的发布策略,在每次发布时我都会得到一些我不能使用的东西,直到最后一次发布时我得到了我可以使用的东西。
This is a simple visualization made by my friend Henrik Kniberg. It beautifully illustrates a broken release strategy where at every release I get something I can’t use, until the last release when I get something I can.
Henrik 建议采用这种替代策略:
Henrik suggests this alternative strategy:
如果我以这种方式计划我的发布,那么在每次发布中我都会提供一些人们可以实际使用的东西。现在,在这个愚蠢的交通示例中,如果我的目标是长途旅行并随身携带一些东西,而你给了我滑板,我可能会感到有点沮丧。我会让你知道带着那东西长途旅行是多么困难——尽管在车道上闲逛很有趣。如果你的目标是让我高兴,你可能会为此感到难过。但你真正的目标是学习,你做到了。所以这很好。你了解到我想去更远的地方旅行,如果你接受了它,你也会了解到我很重视玩得开心。
If I plan my releases this way, in each release I deliver something people can actually use. Now, in this silly transportation example, if my goal is to travel a long distance and carry some stuff with me, and you gave me a skateboard, I might feel a bit frustrated. I’d let you know how difficult it was to travel long distances with that thing—although it was fun to goof around with it in the driveway. If your goal was to leave me delighted, you might feel bad about that. But your real goal was to learn, which you did. So that’s good. You learned I wanted to travel farther, and if you picked up on it, you also learned I valued having fun.
在 Henrik 的进度中,自行车发布前后情况开始好转,因为我实际上可以将其用作足够的交通工具。而且,在摩托车级别,我真的可以看到这对我有用——而且我也很开心。这对我来说可能是最低限度和可行的。如果我真的喜欢摩托车,也许我的下一个最佳选择是更大、更快的哈雷戴维森,而不是跑车。我现在正走向中年危机,哈雷听起来不错。但在我试过摩托车之后,我们都从中学到了一些东西,我们才能做出最好的决定。
In Henrik’s progression, things start picking up at around the bicycle release because I can actually use it as adequate transportation. And, at about motorcycle level, I can really see this working for me—and I’m having fun too. That could be minimum and viable for me. If I really love the motorcycle thing, maybe my next best step would be a bigger, faster Harley-Davidson, and not a sports car. I’m headed for a midlife crisis right now and that Harley is sounding pretty good. But it’s after I try the motorcycle, and we both learn something from that, that we can best make that decision.
将每次发布都视为一次实验,并注意你想要学习的内容。
Treat every release as an experiment and be mindful of what you want to learn.
但是那些需要长途旅行和有孩子的人呢?对于该目标市场,这些都不是好的选择。
But what about other folks who need to travel longer distance, and who have kids? For that target market, none of these would be good choices.
始终牢记您的目标客户、用户和您希望的结果。从所有类型的用户那里获得同样好的结果真的很难。所以专注。
Always keep your target customers, users, and the outcomes you’re hoping for in mind. It’s really tough to get the same great outcome from all types of users. So focus.
我的朋友埃里克所做的是应用经过验证的学习策略——精益创业思想中的一个重要概念。埃里克知道他正在解决的问题,他正在解决的客户和用户,以及他想到的解决方案都是假设。其中很多都是非常好的假设。但它们都是相同的假设。Eric 着手了解这些假设,然后验证它们,从客户和用户面临的问题转向他为他们提供的解决方案。在每一步中,他都以学习某些东西为明确目标来做或构建一些东西。
What my friend Eric did is apply a validated learning strategy—one of the important concepts in Lean Startup thinking. Eric knew that the problems he was solving, the customers and users he was solving them for, and the solutions he had in mind were all assumptions. Lots of them were pretty good assumptions. But they were assumptions just the same. Eric set out to understand the assumptions and then validate them, moving from the problems customers and users faced to the solutions he had for them. At each step he did or built something with the explicit goal of learning something.
Eric 所做的是 Eric Ries 描述的构建-测量-学习循环的核心。根据 Ries 的定义,Eric 发布的每个版本都是最小可行产品。但您可以看到,在他的目标客户和用户眼中,它是不可行的——至少目前还不行。出于这个原因,我喜欢将 Ries 的 MVP 称为最小可行产品实验——或简称 MVPe。这是我可以构建的最小的东西来学习一些东西。我所学到的是推动了解在我的目标客户和用户眼中什么是真正可行的。
What Eric did is the heart of the build-measure-learn loop described by Eric Ries. And by Ries’s definition, each release that Eric shipped was a minimum viable product. But you can see that it wasn’t viable in the eyes of his target customers and users—at least, not yet. For that reason, I like referring to Ries’s MVP as a minimum viable product experiment—or MVPe for short. It’s the smallest thing I could build to learn something. And what I learn is driving toward understanding what’s really viable in the eyes of my target customers and users.
Eric 在此过程中使用了很多工具和技术。但用文字和图片讲故事一直是他工作方式的一部分。使用地图来组织他的故事帮助他在反复改进他的产品以使其可行的过程中牢记他的客户、用户和他们的旅程。
Eric used lots of tools and techniques along the way. But telling stories using words and pictures was always part of the way he worked. Using a map to organize his stories helped him keep his customers, users, and their journey in mind as he iteratively improved his product to viable.
我喜欢用产品发现这个词来描述我们在这个阶段真正做的事情。我们的目标不是建造东西;相反,它是为了了解我们是否在构建正确的东西。碰巧,构建一些东西放在客户面前是了解我们是否正在构建正确的东西的最佳方式之一。我借用了Marty Cagan对发现的定义。[ 6 ]我对发现的定义包括精益创业实践、精益用户体验实践、设计思维实践和大量其他想法。我在发现期间所做的事情不断发展。但目标保持不变:尽快了解我是否正在构建正确的东西。
I like using the term product discovery to describe what we’re really doing at this stage. Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing. I borrow my definition of discovery from Marty Cagan.[6] And my definition of discovery includes Lean Startup practice, Lean User Experience practice, Design Thinking practice, and loads of other ideas. And what I do during discovery continues to evolve. But the goal stays the same: to learn as fast as possible whether I’m building the right thing.
如果我们认识到我们的目标是学习,那么我们就可以最大限度地减少我们构建的内容,而只专注于构建我们需要学习的内容。如果你做得很好,这意味着你早期构建的东西可能还没有准备好生产。事实上,如果是这样,你可能做得太多了。
If we recognize that our goal is to learn, then we can minimize what we build and focus on building only what we need to learn. If you’re doing this well, it means that what you build early may not be production ready. In fact, if it is, you’ve likely done too much.
举个例子:当我是一家为大型连锁零售商构建软件的公司的产品负责人时,我知道我的产品需要在后端的大型 Oracle 数据库上运行。但是数据库人员有时让我很难共事。他们想仔细检查我所做的每一个改变。有时简单的更改需要一周或更长时间。这让我的团队和我的速度放慢了太多。数据库人员的担忧是有道理的,因为所有其他应用程序都依赖于该数据库。打破它对每个人来说都是有风险的。但是他们有一个运行良好的流程来评估和更改数据库——只是花了很长时间。
Here’s an example: when I was a product owner for a company that built software for large, chain retailers, I knew my products needed to run on a big Oracle database on the backend. But the database guys were sometimes a pain for me to work with. They wanted to scrutinize every change I made. Sometimes simple changes would take a week or more. That slowed down my team and me too much. The database guys’ concerns made sense, since all the other applications depended on that database. Breaking it was really risky for everyone. But they had a well-oiled process for evaluating and making database changes—it just took a long time.
对我来说,风险最大的部分是确保我的产品是正确的。因此,我们使用简单的内存数据库构建了软件的早期版本。当然,它们无法扩展,而且我们永远无法向大量普通用户发布我们的早期版本。但是我们早期的最小可行产品实验(当时我们没有这么称呼它们)允许我们用一小部分客户测试想法并且仍然使用真实数据。在与客户进行多次迭代并找到我们认为可行的解决方案之后,我们将更改数据库并将我们的应用程序关闭内存数据库。数据库人员也喜欢我们,因为他们知道当我们做出改变时,我们相信他们是正确的。
The riskiest part for me was making sure my product was right. So we built early versions of software using simple, in-memory databases. Of course, they wouldn’t scale, and we could never release our early versions to a large general audience. But our early minimum viable product experiments (we didn’t call them that then) allowed us to test ideas with a small subset of customers and still use real data. After several iterations with customers, and after we found a solution we believed would work, we’d then make the database changes and switch our application off the in-memory database. The database guys liked us too, because they knew that when we made changes, we were confident they were the right ones.
加里使用地图摆脱了扁平积压陷阱,看到了他的产品的大局,然后真正开始关注它是为谁服务的以及它应该是什么。
Gary used a map to get out of the flat-backlog trap and see the big picture of his product, and then to really start focusing on who it was for and what it should be.
Globo.com 的团队使用地图来协调跨多个团队的大计划,并切出他们认为可行的解决方案的一部分工作。
The teams at Globo.com used a map to coordinate a big plan across multiple teams and slice out a subset of work they believed would be a viable solution.
Eric 使用地图将不太可行的版本分割成最小可行产品实验,这使他能够迭代地找到可行的东西。
Eric used a map to slice out less-than-viable releases into minimum viable product experiments that allowed him to iteratively find what would be viable.
最后一个挑战似乎困扰着软件开发,那就是按时完成。假设您确信自己拥有应该构建的东西。并假设其他人依赖它在特定日期上线。几个世纪以来,艺术家们都知道按时完成的秘诀。在下一章中,我们将学习如何将它应用到软件中。
There’s one last challenge that seems to plague software development, and that’s finishing on time. Suppose you’re confident that you have something that should be built. And suppose others are depending on it going live on a specific date. There’s a secret to finishing on time that’s been known by artists for centuries. In the next chapter, we’ll learn how to apply it to software.
[ 6 ] Marty在2007 年的这篇文章中首次描述了他所说的产品发现的含义。后来,他在他的著作《启发:如何创造客户喜爱的产品》(SVPG 出版社)中对此进行了更详细的描述。
[6] Marty first described what he means by product discovery in this 2007 essay. He later describes it in more detail in his book Inspired: How to Create Products Customers Love (SVPG Press).
这是亚伦和迈克。他们为一家名为 Workiva 的公司工作。Workiva 在名为 Wdesk 的平台上制作了一套产品。它为大公司解决了大问题,它是您可能从未听说过的最大的软件即服务公司之一。
This is Aaron and Mike. They work for a company called Workiva. Workiva makes a suite of products on a platform called Wdesk. It solves big problems for large companies, and it’s one of the biggest software-as-a-service companies you’ve likely never heard of.
Aaron 和 Mike 看起来很开心,不是吗?但这对于共同努力解决棘手问题的人来说是典型的。还是因为右边那个人手里拿着啤酒?不,不是这样。正是这种解决棘手问题的感觉让他们感到高兴。啤酒只是解决棘手问题的奖励。如果你没有因为解决工作中的难题而得到啤酒或同等奖励,你应该找人谈谈。
Aaron and Mike look happy, don’t they? But that’s typical for people who’ve worked together to solve tough problems. Or could it be because the guy on the right has a beer in his hand? Nah, that’s not it. It’s that feeling from having solved a tough problem that’s making them happy. The beer is just a reward for solving the tough problem. If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.
Aaron 和 Mike 刚刚完成了几轮产品发现,他们相信他们有一些应该构建并投入生产的东西。
Aaron and Mike have just completed several rounds of product discovery, and they’re confident they have something that should be built and go into production.
对他们来说,发现始于构建他们正在合作的功能理念,以真正了解它是为谁而构建的,以及他们为什么要构建它。然后他们直接与客户交谈,以验证他们对他们今天的工作方式以及真正问题所在的猜测。之后,他们构建了简单的原型。对于 Aaron 和 Mike,他们能够在 Axure 中构建简单的电子原型并与客户一起远程测试它们——首先看看他们是否重视该解决方案,然后确定它是否可用。对于他们正在开发的功能,他们觉得他们不需要在工作软件中制作原型来了解他们需要什么。
For them, discovery started with framing the feature idea they were working with to really understand who it was for and why they were building it. Then they talked directly to customers to validate their guesses about how they were working today and what the real problems were. After that, they built simple prototypes. For Aaron and Mike, they were able to build simple electronic prototypes in Axure and test them with customers remotely—first to see if they valued the solution, and then to be confident that it was usable. For the feature they were working on, they didn’t feel like they needed to prototype in working software to learn what they needed.
在使用简单原型进行多次迭代后,他们终于确信自己拥有值得构建的东西。这听起来工作量很大,但他们在大约三天内就完成了。他们的最后一步是创建积压工作和交付该功能的计划。这就是他们在图片中的计划。这是个好计划。这就是他们快乐的原因。
After multiple iterations with simple prototypes, they finally felt confident they had something worth building. That may sound like a lot of work, but they did it all in about three days. Their last step was to create a backlog and a plan for delivering the feature. That’s their plan in the picture. It’s a good plan. And that’s why they’re happy.
请务必注意,这张地图并不是关于整个产品,它只是关于他们添加到现有产品的一项功能。这就是为什么它比第 1 章中的 Gary或 Globo.com 团队的小。我告诉你这些是因为有些人错误地认为他们需要映射整个产品来做一个小的改变,他们以此作为不映射的理由。
It’s important to note that this map isn’t about a whole product, it’s just about a feature they’re adding to an existing product. That’s why it’s smaller than Gary’s in Chapter 1, or that of the Globo.com teams. I’m telling you this because some people mistakenly believe they need to map their whole product to make a small change, and they use that as a reason not to map.
仅映射支持对话所需的内容。
Map only what you need to support your conversation.
为了构建这个新功能,这两个人需要与他们的团队建立共识。他们的团队需要能够指出问题和改进的可能性,并估计需要多长时间。这就是他们制作这张最终地图的目的。他们用它来讲述这个功能的故事——从用户的角度一步一步地讲。注意到注入地图的印刷屏幕了吗?他们在浏览地图时指着屏幕并突出显示细节,以便听众可以更好地设想解决方案。迪斯尼使用故事板浏览电影的人对这些人一无所知。
To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story—step by step, from the user’s perspective. Notice the printed screens injected into the map? They pointed at screens and highlighted details while walking through the map so those listening could better envision the solution. The people at Disney who walk through movies using a storyboard have nothing on these guys.
当团队成员询问为什么屏幕会如此运行时,他们会讲述他们尝试过的变体以及用户的行为方式的故事。当团队询问有关输入数据或提交信息时到底发生了什么的详细问题时,这些人已经考虑过并可以回答。或者,当他们不知道时,他们会与团队讨论想法,并在模型中的原型或便签纸上做笔记。他们甚至为他们没有想到的细节添加了一些便利贴,但团队做到了。Aaron 告诉我,团队发现了几个他和 Mike 永远不会发现的技术依赖关系。
When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved. When the team asked detailed questions about exactly what happens when data is entered, or information submitted, these guys had given it thought and could answer. Or, when they didn’t know, they discussed ideas with the team, and made notes on the prototypes or sticky notes in the model. They even added a couple of sticky notes for details they hadn’t thought of, but the team did. Aaron told me that the team spotted several technical dependencies that he and Mike would never have found.
任何长期从事软件开发游戏的人都知道,最大的挑战之一是估计开发实际需要多长时间。我将让您了解良好估算的最保守秘密之一:
Anyone who’s been in the software development game for any length of time knows that one of the biggest challenges is estimating how long development will actually take. I’m going to let you in on one of the best-kept secrets of good estimation:
最好的估计来自真正了解他们正在估计的内容的开发人员。
The best estimates come from developers who really understand what they’re estimating.
有许多方法有望提供更准确的估计。我不打算在这里介绍其中任何一个。但我会告诉你,如果构建软件的人彼此之间以及设想它的人之间没有共同的理解,那么它们都行不通。
There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.
建立共同的理解不应该成为估算的秘密。所以你现在应该去告诉别人。
Building shared understanding shouldn’t be a well-kept secret about estimation. So you should go tell someone else right now.
Workiva 的团队在这一点上不能真正摆脱建设。他们不能像 Globo.com 在第 2 章中所做的那样把事情删掉,因为他们已经证实他们需要这一切。当他们制作原型时,他们能够削减很多并验证他们的解决方案对客户仍然有价值。但是,当你看他们的地图时,它被切成三片。
The team at Workiva can’t really get away with building less at this point. They can’t do what Globo.com did in Chapter 2 and cut things away, because they’ve already validated that they need it all. When they were prototyping, they were able to cut away a lot and validate that their solution was still valuable to customers. But, when you look at their map, it’s cut into three slices.
“他们为什么要关心?” 你可能会问。客户想要的三分之一有点像交付一辆跑车的三分之一。没有人能驾驶它。但 Mike 是产品负责人。在确定一个好的解决方案后,他不会走开。现在他的角色变了,有点像电影里的导演。拍摄每个场景时,他都必须在那里。他必须决定哪些场景应该先拍,哪些场景最后拍。他知道最终整部电影需要组合在一起,看起来像一个连贯的整体。
“Why would they care?” you might ask. A third of what the customers want is sort of like delivering a third of a sports car. No one could drive it. But Mike is the product owner. He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.
因此,迈克与他的团队一起制定了一个发展计划。这就是他们所做的:他们将地图分成三个横切切片。
So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices.
第一个切片贯穿整个功能。一旦他们构建了所有这些部分,他们就可以看到端到端的功能。它不会在所有需要的情况下工作,如果他们以这种方式运送给用户,那些用户会嚎叫。但是 Mike 和他的团队将能够看到软件端到端地运行。他们将能够将真实数据放入其中以查看其性能如何,并且他们可以对其应用一些自动化测试工具以查看其扩展性如何。他们可以学到很多关于以后可能会给他们带来麻烦的技术风险。他们可以更有信心继续前进,他们将能够按时发布。或者,至少他们会发现会减慢他们速度的不可预见的挑战。我将第一个切片称为功能性行走骨架——这是我从 Alistair Cockburn 那里借来的一个术语。我听说其他人称其为“钢丝”或“曳光弹”。
The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”
他们将在第二个切片上分层以构建功能——使其更接近可发布。在此过程中,他们可能会学到一些他们无法预料的事情。他们可能忽略了此功能应具有的一些特征——原型中未探索的更细微之处。他们可能已经发现系统没有按照他们预期的方式运行,需要做一些额外的工作才能获得他们想要的速度。这些是“可预测的不可预测的”——一个与唐纳德拉姆斯菲尔德的“未知的未知数”密切相关的概念。不要假装它们不存在。你知道他们这样做。
They’ll layer on the second slice to build up the functionality—to get it closer to releasable. Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.
最后,他们将在第三个切片上分层以优化特征,使其尽可能完美。他们还会添加一些不可预知的东西。
Finally, they’ll layer on the third slice to refine the feature, to make it as polished as it can be. They’ll also add in some of those unpredictable things.
这些切片中的每一个都不是对客户和用户的发布:它是团队成员用来停下来评估他们所处位置的里程碑。从用户和客户的角度来看,它是不完整的,所以不要让自己感到尴尬。
Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are. From a user and customer perspective it’s incomplete, so save yourselves the embarrassment.
Mike 和 Aaron 的团队估计此功能大约需要两个月的工作。像埃里克一样,他们使用两周的冲刺,所以他们需要四次冲刺。我猜他们本可以做四片,每个冲刺一个,但他们并没有那样想。你也不应该。将这些切片想象成三个不同的桶,每个桶都有不同的学习目标。决定他们将在时机成熟时进入哪些冲刺或迭代。
Mike and Aaron’s team estimated this feature to be about two months’ worth of work. Like Eric, they used two-week sprints, so it would take them four sprints. I guess they could have made four slices, one for each sprint, but they weren’t thinking of it that way. And you shouldn’t, either. Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.
有一件事似乎是秘密,但实际上不应该是秘密,那就是估计是……估计的。访问 Web 并找到任何矛盾修辞法列表。我相信您会在那里找到这个术语:准确估计。如果我们确切地知道事情需要多长时间,那么我们就不会称其为估算,对吗?
One thing that seems to be a secret, but really shouldn’t be, is that estimates are…estimated. Hit the Web and find any list of oxymorons. I’m confident you’ll find this term there: accurate estimate. If we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?
但是,如果您构建少量软件,您可以非常确定的一件事是构建它们花费了多长时间。这就是所谓的测量,而且要准确得多。
But if you build little bits of software, one thing you can be pretty sure of is how long they took to build. That’s called measurement, and that’s quite a bit more accurate.
好吧,这是另一个秘密:你测量得越频繁,你的预测就越好。如果你每天上下班,我怀疑你很擅长预测需要多长时间。如果我问你到达大致相同区域的不同地址需要多长时间,我敢打赌你可以预测在正负 10 分钟内通勤需要多长时间。这就是估算的工作方式。
Ok, so here’s the other secret: the more frequently you measure, the better you get at predicting. If you commute to work every day, I suspect you’re pretty good at predicting how long it’ll take. If I asked you how long it’d take to get to a different address in roughly the same area, I’ll bet you could predict how long commuting there would take within plus or minus about 10 minutes. That’s the way estimation works.
通过将大事物分割成小事物,我们可以获得更多的衡量机会。当然,这有一些微妙之处,但作为一般原则,如果您有更多关于构建类似事物所花费时间的示例,您将获得更好的预测。
By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.
作为产品负责人,Mike 最终要按时发布此功能。他是一个优秀的产品负责人,所以他帮助他的小团队中的每个人也对这个目标负起责任。他将这些早期估计视为他的交付预算。
As a product owner, Mike is ultimately on the hook for getting this feature released on time. He’s a good product owner, so he helps everyone in his small team take some ownership of that goal too. He treats these early estimates as his delivery budget.
Mike 和 Aaron 与他们早期信任的开发人员一起工作,以获得初步的时间估算。他们将其视为预算。他们积极管理它。
Mike and Aaron worked together with developers they trust early on to get an initial time estimate. They treat it as a budget. And they actively manage it.
对于团队构建的每一小块,他们可以衡量构建该块所花费的时间。他们将自己建造的东西视为超出预算的开支。他们可能会发现他们已经完成了预算时间的一半,但只完成了构建功能的三分之一。当然,他们没有预料到这一点,但现在他们意识到了,并且可以为此做点什么。他们可以从他们正在开发的其他功能中借用一些预算。或者,他们可以对不会显着改变用户获得的好处的功能进行小的更改。或者他们可以面对现实,看看他们能做些什么来改变他们承诺交付给的人的期望。
With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.
根据情况的严重程度,他们可能都需要更多啤酒。
Depending on how bad it is, they may all need more beer.
在制定发展战略时,他们会尽早解决可能超出预算的问题。这些都是有风险的事情。与整个团队的对话有助于发现他们。
When slicing out a development strategy, they’ll look to tackle the things that may blow their budget as early as possible. Those are the risky things. And it’s conversations with the whole team that help spot them.
I often ask myself that. OK, I don’t really. But maybe I should.
Mike 和 Aaron 所做的是遵循艺术家使用的及时完成的策略。这是我多年来一直使用的软件。而且,当我第一次在 Globo.com 遇到我的朋友时,我发现他们正在使用它,因为正如我之前提到的,如果他们迟到了为奥运会提供很酷的新互动内容,奥林匹克委员会将不会重新安排奥运会. 我想这个策略是您甚至不假思索地经常使用的策略。
What Mike and Aaron have done is to follow a strategy used by artists to finish in time. It’s one I’ve used for years with software. And, when I first met my friends at Globo.com, I found it’s one they use, because as I mentioned before, if they’re late with cool, new interactive stuff for the Olympics, the Olympic committee won’t reschedule the Olympics. I’ll guess this strategy is one you even use routinely, without thinking.
让我先解释一下达芬奇不做什么。但是,不幸的是,这往往是人们构建软件确实尝试做的事情。
Let me first explain what da Vinci doesn’t do. But, unfortunately, it’s too often what people building software do try to do.
假设你是达芬奇,你想创作一幅画,并且正在按照一个天真的软件团队的方式工作。[ 7 ]你可以从你认为在你的脑海中清晰的画面开始。然后你把这幅画分成几个部分。假设你有五天的时间来画这幅画。每天你都会画更多的部分。在第五天结束时,Huzzah!——你完成了!什么可以更简单?
Suppose you were da Vinci, and you wanted to create a painting and were working the way a naïve software team does.[7] You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah!—you’re done! What could be simpler?
只是,它不是那样工作的——至少对艺术家来说不是这样。这种创造事物的方式假设我们的愿景是正确和准确的。它还假设了一些关于创作者的技能以及她在不在上下文中看到它们的情况下精确定义零件的能力。如果你在软件开发中这样做,它被称为增量策略。这就是瓦匠砌墙的方式。如果每一块都像砖一样有规则的大小和明确的定义,它就会起作用。
Only, it doesn’t work like that—at least not for artists. This way of creating things assumes our vision is correct and accurate. It also assumes something about the skill of the creator and her ability to precisely define parts without seeing them in context. If you do this in software development, it’s called an incremental strategy. It’s the way a bricklayer might build a wall. And it works if each piece is as regularly sized and well defined as a brick.
当我小时候画画的时候,我就掉进了这个陷阱。我经常画某种动物,然后从头开始。我会一直画到完美为止,然后继续画身体的其余部分——腿、尾巴等等。当我接近完成时,我可以看到我的动物的比例有点不对劲。头部对于身体的其他部分来说太大或太小。腿似乎扭曲成一个奇怪的角度。而这个生物的姿势似乎有点僵硬。至少,这是我作为一个才华横溢的六岁孩子的看法——所有六岁的孩子都是才华横溢的艺术家。
When I used to draw as a kid, I fell into this trap. I’d often be drawing some sort of animal and start with the head. I’d work on that ‘til it was perfect, then continue to draw the rest of the body—legs, tail, and so on. By the time I got close to done, I could see that the proportions of my animal had gotten a bit off. The head was too big, or too small for the rest of the body. The legs seem to be twisted at an odd angle. And the pose of the creature just seemed a bit stiff. At least, that was my perspective as a talented six-year-old—and all six-year-olds are talented artists.
晚年我才知道先画整个构图对我有好处。从那里我可以得到正确的比例,并改变生物的姿势。我什至可能会重新考虑我要画什么。
It was later in life that I learned I’d benefit from sketching the whole composition first. From there I could get proportions right, and make changes to the pose of the creature. I’d maybe even reconsider what I was going to draw.
我没有和达芬奇在一起,但我希望他也做了同样的事情。
I wasn’t there with da Vinci, but I expect he did something much the same.
甚至达芬奇也可能承认他的远见并不完美,并且他在创作这幅画时会学到一些东西。第一天,我想他先画了构图草图,或者可能画了淡淡的底色。我可以想象他此时正在改变构图。“嘿,我认为微笑将是一个重要的部分。我会把她的手从嘴里移开。背景中的那些山脉……太多了。”
Even da Vinci would probably acknowledge that his vision wasn’t perfect, and that he’d learn something as he was creating the painting. On day one, I imagine he first sketched the composition, or maybe did a light underpainting. I can imagine him at this point making changes to the composition. “Hey, I think the smile is going to be an important part. I’ll move her hand away from her mouth. And those mountains in the background…too much.”
到周中,达芬奇为这幅画添加了许多颜色和形式,但他仍在不断地进行修改。到周末时,他知道自己的时间不多了,所以他所有的精力都转移到了完善这幅画上。有人想知道蒙娜丽莎没有眉毛是故意的选择,还是达芬奇只是没时间添加一个新的、完全精致的特征。
By midweek, da Vinci is adding lots of color and form to the painting, but he’s still making changes as he goes. By the end of the week, he knows he’s running out of time, so all his effort shifts to refining the painting. One wonders if the Mona Lisa missing her eyebrows was a deliberate choice, or if da Vinci simply ran out of time to add a new, fully refined feature.
伟大的艺术永远不会完成,只会被抛弃。— 列奥纳多·达·芬奇
Great art is never finished, only abandoned. — Leonardo da Vinci
这句话出自达芬奇之手,它表达了我们可以永远继续添加和完善的概念,但在某些时候,我们需要交付产品。而且,如果达芬奇的作品和许多其他艺术家的作品都是很好的例子,那么我们——欣赏作品的人——不知道它被遗弃了。对我们来说,它看起来已经完成了。
That quote is attributed to da Vinci, and it speaks to the notion that we could continue to add and refine forever, but that, at some point, we need to deliver the product. And, if da Vinci’s work and that of lots of other artists are good examples, we—the people who appreciate the work—have no idea it was abandoned. To us, it looks finished.
艺术家或作家就是这样工作的。事实上,制作早报或晚报的人就是这样工作的。创造现场戏剧的人就是这样工作的。任何必须在截止日期前交付并边做边学的人都认可这种策略。
An artist or author works this way. In fact, the people who put together the morning paper or evening news work this way. The people who create live theater work this way. Anyone who must deliver on a deadline, and learn as he goes, recognizes this strategy.
使用迭代思维来评估和更改您已经完成的工作。
Use iterative thinking to evaluate and make changes to what you’ve already made.
在软件开发中,迭代有两个含义。从过程的角度来看,就是一遍又一遍地重复同样的过程。这就是为什么敏捷开发中使用的开发时间盒通常被称为迭代的原因。但是当你使用这个术语来描述你正在用你构建的软件做什么时,它意味着评估和改变它。在构建之后更改软件通常被视为失败。在这里,糟糕的需求或范围蔓延等术语被用来谴责那些决定构建什么的人。但我们都知道,改变是学习的必然结果。
In software development, iterate has two meanings. From a process perspective, it means to repeat the same process over and over. That’s why the development time-box used in Agile development is often called an iteration. But when you use this term to describe what you’re doing with the software you build, it means to evaluate and change it. And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.
使用增量思维进行添加。
Use incremental thinking to make additions.
不幸的是,我们很容易陷入迭代的漩涡中。所以我们必须密切关注日历并不断增加更多内容。艺术家不仅通过在绘画中添加全新的东西来添加更多,而且还通过构建已经添加的东西来添加更多。
Unfortunately, we can easily get trapped in the whirling eddies of iteration. So we’ve got to keep our eye on the calendar and keep incrementally adding more. The artist adds more not only by adding whole new things to a painting, but also by building up things that were already added.
您可以通过首先创建一个没有任何额外功能的简单版本来在软件中做同样的事情。您可能会认为这是您的草图。使用简单版本后,您可以通过向其添加更多功能来构建它。随着时间的推移,它逐渐成为您和其他人最初设想的最终版本。如果事情进展顺利,它会构建出与您最初预想不同的东西,但会更好,因为它会受益于您所学到的知识。
You might do the same things in software by first creating a simple version of functionality without any extras. You might think of this as your sketch. After using the simple version, you’d build it up by adding more functionality to it. Over time, it builds up to be the finished version you and others may have originally envisioned. If things go really well, it builds up to something different than you originally envisioned, but better because it benefits from what you’ve learned.
这可能会让你有点头疼,但我会在这里混合一些比喻。在创建软件时,我个人依赖基于国际象棋比喻的策略。我是一个几乎不会下棋的废棋手,所以如果我用错了这个比喻,你不准给我写信和纠正我。无论产品或功能发布多小,我都喜欢将我的发布积压分为三组:
This may hurt your head a bit, but I’m going to mix some metaphors here. I personally rely on a strategy based on a chess metaphor when creating software. I’m a crap chess player who barely knows how to play the game, so if I’m misusing the metaphor, you’re not allowed to write me and correct me. No matter how small the product or feature release, I prefer to slice my release backlog into three groups:
如果您已经发现了您认为对客户和用户而言可行的首次发布,那么作为一个团队一起工作,将首次公开发布再次分成开场游戏、中期游戏和结束游戏故事。创建产品的团队最擅长识别风险和学习机会所在的位置。他们会对共同制定的计划产生强烈的主人翁意识。
If you’ve discovered what you believe is a viable first release to customers and users, work together as a team to slice that first public release again into opening game, mid game, and endgame stories. The team creating the product is best at identifying where the risks and opportunities to learn are. They’ll feel the strongest ownership over the plan they create together.
这就是 Aaron 和 Mike 在他们整个开发团队的帮助下所做的。再看看他们多开心。
That’s what Aaron and Mike did with the help of their whole development team. Look again at how happy they are.
在第 3 章中,埃里克不得不应对识别错误产品的风险。他采用了一种拆分发布的策略,使他能够将整个产品呈现在客户面前。
In Chapter 3, Eric had to deal with the risk of identifying the wrong product. He used a strategy of slicing out releases that allowed him to put whole products in front of customers.
在本章中,Aaron 和 Mike 专注于技术风险,这些风险可能会破坏他们的交付计划或导致该功能的成本远远超过他们的预期。他们不会在每个周期结束时向客户和用户展示他们最终得到的结果,因为他们已经知道这还不够。但是他们会自己和他们的团队认真认真地审视它,并使用他们学到的知识来安全地引导此功能的开发。
In this chapter, Aaron and Mike are focused on technical risk, the things that might blow their delivery schedule or cause the feature to cost much more than they expected. They won’t show what they end up with at the end of every cycle to customers and users because they already know it’s not sufficient. But they’ll take a good, hard look at it themselves and with their team, and use what they learn to safely steer the development of this feature.
这很微妙,但您可能已经在第 2 章中发现,Eric 进行了两次为期两周的冲刺,以构建他的下一个最小可行产品实验。他必须决定在第一个冲刺中构建哪些东西,在第二个冲刺中构建哪些东西。他用这种思维来做出那些决定。他和他的团队把有风险的部分放在首位——Eric 或他的团队希望尽快看到工作的部分,以便他们可以在将其呈现给客户之前纠正路线。
It’s subtle, but you might have caught in Chapter 2 that Eric was taking two two-week sprints to build his next minimum viable product experiment. And he had to decide which things to build in the first sprint, and which to build in the second sprint. He used this kind of thinking to make those decisions. He and his team put the risky bits first—the parts that Eric or his team wanted to see working sooner so that they could course-correct before they put it in front of their customers.
您已经看到了为不同目的构建和使用地图的四个非常好的示例。我们将在后面的章节中探讨更多使用地图的方法。但在你走得太远之前,我想向你展示我最喜欢的教别人如何绘制地图的技巧。我保证,如果您尝试一下,从那一刻起您就会像专家一样绘制地图。
You’ve seen four pretty good examples of building and using maps for different purposes. There are a lot more ways to use maps that we’ll explore in later chapters. But before you get too far, I want to show you my favorite trick for teaching others how to map. I promise if you try it, you’ll map like an expert from that moment on.
让我们从第 5 章开始。
Let’s pick up there in Chapter 5.
[ 7 ]我从 John Armitage 2004 年的论文“Are Agile Methods Good for Design?”中得到了这个简单可视化的想法。约翰以这种方式描述了接近用户体验设计。我建议我们也将这个比喻带入我们的构建方式中。
[7] I got the idea for this simple visualization from John Armitage’s 2004 paper “Are Agile Methods Good for Design?” John describes approaching user experience design this way. I’m suggesting we carry the metaphor into the way we build as well.
如果您认为创建故事地图是复杂的、神秘的,或者以任何方式难以做到,那么现在让我向您保证,事实并非如此。事实上,您已经了解用于创建地图的所有基本概念。现在让我们来看一个取自日常生活的例子。而且,为了简单起见,我们将用你的生命。在此过程中,我将为您已经了解的那些重要概念命名。
If you think that creating a story map is complicated, or mystical, or in any way hard to do, let me assure you right now that it’s not. In fact, you’re already wired to understand all the basic concepts used to create a map. Let’s work through an example right now, taken from everyday life. And, to make it simple, we’ll use your life. Along the way I’ll give some names to those important concepts you already understand.
拿起便签本和一支笔,跟我来。别担心——慢慢来。我会等。
Grab a pad of sticky notes and a pen, and follow along with me. Don’t worry—take your time. I’ll wait.
准备好?
Ready?
闭上眼睛,回想你今早醒来的那一刻。你今天早上确实醒了,对吧?你记得做的第一件事是什么?现在,睁开眼睛,把它写在便利贴上。我会和你一起写。我的第一张便利贴上写着,“打瞌睡。” 不幸的是,通常是这样。在糟糕的早晨,我可能不得不打两三下。
Close your eyes, and think back to the moment you woke up this morning. You did wake up this morning, right? What’s the first thing you recall doing? Now, open your eyes, and write it down on a sticky note. I’ll write along with you. My first sticky note says, “Hit snooze.” Unfortunately, it usually does. On bad mornings I may have to hit it two or three times.
现在,撕掉那张胶粘物,把它放在你面前的桌子上。然后,想想你接下来做的事情。知道了?现在,把它写在下一张便利贴上,撕下,贴在第一张便利贴旁边。然后继续。我接下来的几张即时贴上写着,“关掉闹钟”和“跌跌撞撞地去洗手间”。
Now, peel off that sticky and put it on the table in front of you. Then, think of the next thing you did. Got it? Now, write it on the next sticky, peel it off, and place it next to the first one. Then keep going. My next couple of stickies say, “Turn off alarm” and “Stumble to the bathroom.”
继续写便签,直到你准备好工作,或者无论你今天在做什么。我通常以“上车”结束,开始开车上班。我预计您需要三四分钟才能写完所有便签。
Keep writing sticky notes until you’ve gotten ready for work, or whatever you’re doing today. I usually end with “Get into my car” to start my drive for work. I expect it’ll take you three or four minutes to write all your stickies.
看看你写的所有便利贴。注意到它们都是如何以动词开头的吗?好吧,几乎所有的人。这些简短的动词短语,如“Take a shower”和“Brush teeth”是任务,意思是我们为了达到目标而做的事情。当我们描述人们使用我们的软件为实现他们的目标而执行的任务时,我们将它们称为用户任务。这是构建好的故事地图最重要的概念——更不用说编写和讲述好故事了。您会发现故事地图中几乎所有关于人们使用您的软件做什么的便签都使用这些简短的动词短语。
Take a look at all the sticky notes you wrote. Notice how all of them start with a verb? Well, almost all of them. These short verb phrases like “Take a shower” and “Brush teeth” are tasks, which just means something we do in order to reach a goal. When we describe the tasks people using our software do in order to reach their goals, we’ll call them user tasks. It’s the most important concept to building good story maps—not to mention writing and telling good stories. You’ll find that almost all the sticky notes in story maps about what people do using your software use these short verb phrases.
现在停在这里一分钟,想想那是多么容易。我让你写下你做了什么,你的脑子里自然而然地出现了任务。我认为最重要的概念是最自然的,这很酷。
Now stop here for a minute and think about how easy that was. I asked you to write down what you did, and naturally out of your brain tasks came out. I think it’s pretty cool that the most important concept is the most natural.
不要太在意任务这个词。如果您是项目经理,您会注意到项目计划中充满了任务。如果您一直在敏捷开发中使用故事,您就会知道规划工作涉及编写大量的开发和测试任务。如果你既不是项目经理也不是软件开发人员,当你使用任务这个词时要小心,因为其他人可能会认为你指的是他们通常想到的那种任务,他们会告诉你你用错了.
Don’t get too hung up on that word task. If you’re a project manager, you’ve noticed project plans are full of tasks. If you’ve been using stories in Agile development, you know that planning work involves writing a bunch of development and testing tasks. If you’re neither a project manager nor a software developer, watch out when you use the word task because those other people might think you mean the kind of tasks they usually think about, and they’ll tell you you’re using it wrong.
用户任务是故事地图的基本构建块。
User tasks are the basic building blocks of a story map.
现在,数一数你写下的任务数。
Now, count the number of tasks you wrote down.
大多数人写在 15 到 25 之间。如果你写得更多,那就太棒了。如果你写得少,伙计,你的生活就会很简单。我希望我能在早上这么快就做好准备。但是您可能想回顾一下您的列表,看看是否有任何您跳过的内容。
Most people write somewhere between 15 and 25. If you wrote more, that’s fabulous. If you wrote less, man, you’ve got a simple life. I wish I could get ready in the morning that quickly. But you may want to look back at your list and see if there’s anything you skipped writing down.
我相信这不会让您感到惊讶,但人与人之间是不同的。您会在他们选择做事的方式上看到这些差异。
I’m sure this doesn’t come as a surprise to you, but people are different from one another. You’ll see these differences expressed in the way they choose to do things.
例如,有些人几乎每天早上都有锻炼的动力和自律。如果你写了几个与锻炼相关的任务,那你太棒了!我自己仍在努力。
For instance, some people have both the motivation and self-discipline to exercise almost every morning. If you wrote a couple of tasks related to exercise, you rock! I’m still working on that myself.
有些人只是因为他们居住的家庭而承担了更多的责任。如果你有孩子,我保证你会写下一些没有孩子的人没有的任务。如果你有一只狗,你可能会有一两个任务专门用来照顾这只狗。
Some people simply have more responsibilities because of the household they live in. If you’ve got kids, I promise you wrote down several tasks that people without kids didn’t. If you have a dog, you may have a task or two dedicated to taking care of the dog.
当您考虑使用您的软件的人时,请记住这一点。他们在使用它时可能有不同的目标。他们可能会在不同的环境中使用它,迫使他们考虑其他人或事物。
Keep that in mind when you’re thinking about people using your software. They may have different goals when using it. They may use it in different contexts that force them to take into account other people or things.
在这个练习中,有些人只是写了比其他人更多的细节。他们可能会说“做早餐”之类的东西,而不是写“把面包放进烤面包机”、“倒一杯果汁”,或者,如果你是我妻子的话,“在冰沙里加羽衣甘蓝”,这是其中一个我真的很讨厌她做的任务。
In this exercise, some people just write a lot more details than others. They might take something like “Make breakfast” and instead write “Put bread in the toaster,” “Pour a glass of juice,” or, if you’re my wife, “Add kale to the smoothie,” which is one of the tasks I really hate her doing.
任务就像石头。如果你拿一块大石头用锤子敲它,它会碎成一堆小石头。那些较小的岩石仍然是岩石。任务也是一样。现在我不知道什么时候石头大到可以称为巨石,什么时候小到可以称为鹅卵石,但是有一种很酷的方法可以区分大任务和小任务。
Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks. Now I don’t know when a rock is big enough to be called a boulder, or small enough to be called a pebble, but there’s a cool way to tell a big task from a small task.
我的朋友 Alistair Cockburn 描述了目标水平的概念在他的书Writing Effective Use Cases (Addison-Wesley Professional) 中。别担心,我们不会开始编写用例。只是当我们谈论人类行为时,这个概念真的很有用。
My friend Alistair Cockburn described the goal level concept in his book Writing Effective Use Cases (Addison-Wesley Professional). Don’t worry, we’re not going to start writing use cases. It’s just that the concept is really useful when we’re talking about human behavior.
阿利斯泰尔使用海拔比喻,海平面在中间,其他一切要么高于海平面,要么低于海平面。海平面任务是我们希望在有意停下来做其他事情之前完成的任务。您是否在任务列表中写下了“洗澡”?这是一项海平面任务,因为您不会在淋浴进行到一半时想,伙计,这场淋浴正在拖延。我想我会喝杯咖啡,稍后再洗完澡。Alistair 称这些功能级任务并用一点海浪来注释它们。但我只是称它们为任务。
Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.
像“洗澡”这样的任务会分解成许多更小的子任务,比如“调节水温”和“洗头”,如果你是我妻子,还有一些涉及丝瓜去角质的东西。请记住,人是不同的,您会在他们处理任务的方式上看到行为差异。阿利斯泰尔用一条小鱼来注释这些,因为它们在海底。
Tasks like “Take a shower” break down into lots of smaller subtasks like “Adjust water temperature” and “Wash hair,” and, if you’re my wife, something involving an exfoliating loofah thing. Remember, people are different, and you’ll see behavior differences in the way they approach tasks. Alistair annotates these with a little fish because they’re below the ocean.
最后,我们可以将一堆任务汇总成一个摘要级任务。淋浴、刮胡子、刷牙,以及早上起床后所做的所有其他事情都可以归结为一项摘要任务。不过,我不确定我会怎么称呼它。“收拾干净了吗?” “早上沐浴?” 沐浴是一个愚蠢的词。不要用那个。
Finally, we could roll up a bunch of tasks into a summary-level task. Taking a shower, shaving, brushing teeth, and all that other stuff you do in the morning after you get out of bed could roll up into a summary task. I’m not sure what I’d call it, though. “Getting cleaned up?” “Morning ablutions?” Ablutions is a silly word. Don’t use that.
使用目标级别的概念来帮助您聚合小任务或分解大任务。
Use the goal-level concept to help you aggregate small tasks or decompose large tasks.
如果您还没有这样做,请按照从左到右的顺序组织您的任务,先做的在左边,后来做的在右边。
If you haven’t done this already, organize your tasks in a left-to-right flow with what you did first on the left, and what you did later on the right.
试着讲一个故事,指着第一个便利贴说,“首先我做了这个,”然后指着下一个便利贴说,“然后,我做了这个。” 现在继续从左向右移动并讲述您的故事。你可以看到每个便利贴都是一个步骤,隐藏在每个便利贴之间的是漂亮的连词“……然后我……”
Try telling a story by pointing at the first sticky note and saying, “First I did this,” and then pointing to the next sticky and saying, “then, I did this.” Now keep going moving from left to right and telling your story. You can see that each sticky note is a step, and hidden in between each sticky note is the nifty little conjunction phrase “…and then I…”
我将这种从左到右的顺序称为叙事流程,它是“讲故事顺序”的一种奇特说法。我们将把这整个东西称为地图并且叙事流是它的从左到右的轴。
I’ll call this left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.” We’ll call this whole thing a map and that narrative flow is its left-to-right axis.
哇,我的流量变得非常广泛。我开始堆叠同时发生的事情。当我布置流程时,我发现我已经错过了一些细节,我正在尝试确定它们是否重要。
Wow, my flow got pretty wide. I started stacking things that happen in and around the same time. As I lay out the flow, I see I already missed a few details, and I’m trying to decide if they matter.
地图使用叙事流程从左到右组织:您讲述故事的顺序。
Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.
这种便签排列的妙处在于它让我们看到了整个大故事。查看以叙事流程组织的故事可以让您更轻松地看到故事中缺失的部分。
The cool thing about this arrangement of sticky notes is that it allows us to see the whole big story. Seeing the story organized in a narrative flow allows you to more easily see the parts of the story that are missing.
回顾你的成长地图,寻找你可能错过的步骤。
Look back at your growing map and look for steps you might have missed.
我又加了几个。我决定不写下海平面以下的许多细节。如果我这样做了,就会有数百个便利贴。
I added just a few more. There’s lots of details that are below sea level that I’ve decided to not write down. If I did, there’d be hundreds of stickies.
到目前为止,这是显而易见的,对吧?学习这个几乎不值得你浪费纸张。但是等等,它会变得有趣。
So far this is dead obvious, right? Learning this was hardly worth the paper you’re wasting. But wait, it’s about to get interesting.
花点时间想想你昨天早上做了什么。如果你昨天早上做的事情和今天早上做的不一样,把它们写下来并添加到你的地图上。
Take a minute and think about what you did yesterday morning. If there are different things you did yesterday morning than you did this morning, write them down and add them to your map.
想想事情出错的早晨。如果没有热水怎么办?你当时做了什么?如果你没有牛奶或麦片或任何你通常早餐吃的东西怎么办?如果您的女儿因为忘记完成今天要交的家庭作业而陷入恐慌怎么办,这是我家时不时发生的事情。然后呢?为您要执行的操作编写任务并将其添加到地图中。
Think of mornings when things went wrong. What if there was no hot water? What did you do then? What if you were out of milk or cereal or whatever you normally eat for breakfast? What if your daughter flew into a panic because she forgot to do her homework that’s due today, which is what happens in my house every once in a while. Then what? Write tasks for what you’d do and add them to the map.
现在,想想你理想中的早晨。什么会让你的早晨变得完美?对我来说,就是做点运动,享受一顿丰盛的早餐,同时继续阅读。但那样我就得早点起床,停止打瞌睡。
Now, think about your ideal morning. What would make your morning perfect? For me, it would be getting some exercise and enjoying a long breakfast while I catch up on some reading. But then I’d have to get up a lot earlier and stop hitting snooze.
另请注意,您需要将一些任务放在一列中,这既是为了节省空间,也是因为它们看起来与您通常可能执行的其他任务相似。例如,您可能会发现自己有做一顿非常棒的早餐的任务,您可以将这些任务与通常做的快速早餐的任务一起放在一个列中。
Notice also that you’ll want to put some tasks in a column, both to save space and because they seem similar to other tasks you might normally do. For example, you might find that you’ve got tasks for making a really great breakfast that you can put in a column along with the tasks for making the quick breakfast you normally make.
我的朋友 David Hussman 称之为“玩什么”,你可能还记得第 2章和第 3章中的一个短语。不幸的是,我们可以玩很长时间的 What-About 并使这张地图变大。我在我的地图上添加了一些东西,专门用于我希望做的事情,比如锻炼身体或在早餐时做一些放松的阅读。我还添加了一些通常在早上发生的更常见的替代方案。
My friend David Hussman calls this “playing What-About,” a phrase you might remember from Chapter 2 and Chapter 3. Unfortunately, we could play What-About for a long time and make this map huge. I added a few more things to my map specifically for things I wish I’d done, like exercising or doing a bit of relaxing reading during breakfast. I also added a few more common alternatives that often happen in the morning.
详细信息、备选方案、变体和例外情况填充在地图的主体中。
Details, alternatives, variations, and exceptions fill in the body of a map.
请注意,当您开始添加这些新任务时,您可能不得不重新组织您的叙述流程。我知道我做到了。例如,我需要在起床和洗澡之间进行锻炼。而且我必须添加“穿上运动服”,这与淋浴后的“穿好衣服”步骤不同。
Notice that when you start to add these new tasks, you’ll likely have to reorganize your narrative flow. I know I did. For instance, I’d need to slip that exercise thing in between getting up and taking a shower. And I’d have to add in “Put on exercise clothes,” which isn’t the same as the “Get dressed” step after taking a shower.
如果你放松并把事情放在看起来自然的地方,你会发现一个感觉正确的叙事流程。当你现在讲述你的故事时,你会发现你可以用很多不同的方式来讲述它。您可以讲述典型的日常故事、美妙的日常故事以及发生一两次紧急情况的故事——所有这些都可以通过在您从左到右讲故事时指向不同的即时贴来完成。尝试使用其他一些连词将您的任务粘合在一起。你可能会说,“我通常这样做,但有时我会这样做”或“我这样做,或这样做,然后再这样做。” (我希望你用你实际做的来填写这个词,因为我从这里看不到你指的是什么。)
If you relax and put things where it seems natural, you’ll find a narrative flow that feels right. When you tell your story now, you’ll find that you can tell it a bunch of different ways. You can tell the typical day story, the fabulous day story, and the story that has an emergency or two—all by pointing at different stickies as you talk through it from left to right. Try using some other conjunctions to glue your tasks together. You might say, “I usually do this, but sometimes I do this” or “I do this, or this, and then this.” (I’m expecting you to fill in the word this with what you actually do, because I can’t see what you’re pointing at from here.)
小时候,有一套很受欢迎的儿童读物系列,叫做《选择你自己的冒险》. 也许你还记得他们。这个想法是,你会读到一个部分的末尾,然后有几个关于故事主人公接下来会做什么的选择。每个选择之后是一个页码。做出选择后,您将转到该页面并从那里继续阅读故事。说实话,我从来都不喜欢那些书。无论我做出什么选择,我似乎总是在同一个地方结束;似乎从来没有足够的选择来进行一次真正伟大的冒险。地图有点像那样,但更好。通过地图的方式几乎是无限的——如果你考虑真实的人可能使用软件产品来实现他们的目标的方式,这实际上是非常准确的。
When I was a kid, there was a popular series of children’s books called Choose Your Own Adventure. Maybe you remember them. The idea was that you’d read to the end of a section and then be given a couple of choices about what the hero of the story would do next. After each choice was a page number. Once you made your choice, you would turn to that page and continue reading the story from there. Truthfully, I was never a fan of those books. I always seemed to end up at the same place no matter what choice I made; there never seemed to be enough choices to make a really great adventure. The map works a little like that, except better. The number of ways through a map is almost limitless—which, if you’re thinking about the way real people might use a software product to meet their goals, is actually pretty accurate.
如果你想让事情变得真正具有挑战性,请与几个与你一起工作的人一起做这个练习。关于与你一起工作的人,你会学到比你想知道的更多的东西,而且你会发现每个人都同意的叙述流程会很有趣。我所说的“乐趣”是指“争论”。总是有人在洗澡前吃早餐,有人在洗澡后吃早餐。有一个关于刷牙的大争论——你是在早餐前刷牙还是早餐后刷牙,还是两者都刷牙?
If you want to make things really challenging, do this exercise with a couple of people you work with. You’ll learn more than you ever wanted to know about the people you work with, and you’ll have a bit of fun finding a narrative flow everyone agrees on. By “fun,” I mean “argument.” There are always people who eat breakfast before showering, and some who eat after. There’s the great tooth-brushing debate—do you brush before or after breakfast, or both?
放松。
Relax.
如果你在争论,这可能意味着这无关紧要。例如,将早餐放在淋浴之前或之后是个人喜好问题。选择与您一起工作的小组最常见的内容。你会发现人们不会为重要的事情争论不休。例如,将“穿好衣服”放在“洗澡”之后不仅仅是偏好问题。反过来做会导致穿着湿衣服上班。
If you’re arguing, it likely means that it doesn’t matter. For instance, putting breakfast before or after taking a shower is a matter of preference. Go with what’s most common for the group you’re working with. You’ll find people won’t argue about things that do matter. For example, putting “Get dressed” after “Take a shower” isn’t just a matter of preference. Doing it the other way around results in showing up to work wearing wet clothes.
到目前为止,您的地图应该看起来很宽,如果您已经探索了很多选项,可能会有点深。它可能有 30 个或更多任务。它看起来应该像某种奇怪动物的脊椎和肋骨。
By now, your map should be looking pretty wide, and if you’ve explored lots of options, maybe a little deep. It’ll likely have 30 or more tasks. It should look like the spine and ribs of a weird animal.
如果你退后一步,从左到右查看你的地图,你会发现有一堆故事似乎是连在一起的——例如,你在浴室里做的所有准备工作,或者所有这些事情在厨房里做早餐,或者检查天气,拿一件外套,把你的笔记本电脑或其他你在离开家之前需要的东西装在你的包里。你能看到那些似乎在一起帮助你实现更大目标的任务群吗?
If you step back a bit and look across your map from left to right, you’ll find there are bunches of stories that seem to go together—for instance, all those things you do in the bathroom to get ready, or all those things in the kitchen to make breakfast, or that junk you do to check the weather, grab a coat, and load your bag with your laptop or other stuff you’ll need before leaving the house. Can you see those clusters of tasks that seem to go together to help you reach a bigger goal?
在这些相似的便签簇中的每一个上方,放一张不同颜色的便签。在上面写一个简短的动词短语,提炼出它下面的所有任务。
Above each of these clusters of similar stickies, put a different colored sticky note. Write a short verb phrase on it that distills all the tasks underneath it.
如果你没有不同颜色的便利贴,我会告诉你一个秘密。每包便利贴都有两种形状!将便利贴旋转 45 度,噗,你得到了一个很酷的菱形。如果您想使粘性看起来不同,请使用它。
If you don’t have a different color of sticky note, I’ll let you in on a secret. Every package of sticky notes comes with two shapes! Rotate a sticky note 45 degrees and, poof, you’ve got a cool diamond shape. Use that if you want to make a sticky look different.
这些具有更高目标级别任务的便签称为活动。活动组织了由相似的人在相似的时间完成的一系列任务,以达到特定的目标。当您阅读地图顶部的活动时,它们也处于叙述流程中。一排便利贴是地图的主干。如果您有一张地图,里面有很多便签纸并且您想分享它,一个好的开始方法是讲一个高层次的故事。只需阅读地图的主干部分,每个活动之间都有“……然后他们……”连词。
These sticky notes with a higher goal-level task are called activities. Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal. When you read the activities across the top of the map, they’re in a narrative flow, too. The row of stickies is the backbone of the map. If you’ve got a map with lots of stickies in it and you wanted to share it, a good way to start is by telling a high-level story. Just read the backbone of the map, with the “…and then they…” conjunction between each activity.
活动聚合了针对共同目标的任务。
Activities aggregate tasks directed at a common goal.
这是我的成长地图,其中添加了活动以赋予地图主干。它使阅读和查找内容变得更容易,至少对我而言。这让我更容易真正了解早上发生的事情。
Here’s my growing map with activities added to give the map a backbone. It makes it easier to read and find things, at least for me. And it makes it easier to really get the big picture of what’s going on in my morning.
活动和高级任务构成了故事地图的支柱。
Activities and high-level tasks form the backbone of a story map.
活动似乎不像任务那样有共同语言。例如,您在离开家之前做的那件事叫什么?你收拾包包、查找购物清单、查看天气并在需要时带上雨伞的那种东西?我可以称之为“收拾垃圾”。你可能会称它为不同的东西。
Activities don’t seem to have common language the way tasks do. For instance, what do you call that thing you do before leaving the house? That thing where you gather up your bag, find a shopping list, check the weather, and grab an umbrella if you need it? I could call it “gathering up my junk.” You might call it something different.
当你为你的产品和你的客户构建这些时,你会想要他们怎么称呼它。
When you build these for your products and your customers, you’ll want to call it what they call it.
现在,这是非常酷的部分 — 您可以使用地图来帮助您想象未发生的事情的部分。
Now, here’s the really cool part—the part where you get to use the map to help you imagine something that didn’t happen.
如果您查看已构建的地图,您可能会在左侧边缘的某处看到“打瞌睡”或“关闭闹钟”。想象一下,今天早上你可以跳过那个。你可以跳过它,因为昨晚你忘记设置闹钟了。你猛地睁开眼睛,看了看你的时钟,你发现你需要在几分钟内到达某个地方。你真的来晚了!不要惊慌——我们只是在假装。
If you look at the map you’ve built, you’ll probably see “Hit snooze” or “Turn off alarm” somewhere on the left edge. Imagine that this morning you can skip that one. You can skip it because last night you forgot to set your alarm. Your eyes shot open and looked at your clock and you saw you needed to be somewhere in just a few minutes. You’re really late! Don’t panic—we’re just pretending.
在便利贴上写下“几分钟后出门”,并将其放在地图左侧靠近顶部的位置。现在,想象一条线从左到右穿过地图的中间——有点像腰带。现在,如果您不想在几分钟内完成离开的目标,请将所有任务移至该线下方。不要将活动向下移动,即使它们下面没有任务。让活动中没有任务可以让你表明你今天早上不会达到那个目标。
Write “Get out the door in a few minutes” on a sticky and place it to the left of the map near the top. Now, imagine a line slicing through the middle of the map left to right—kinda like a belt. Now, move all the tasks below that line if you wouldn’t do them to reach the goal of getting out in a few minutes. Don’t move the activities down, even if there are no tasks left under them. Having the activity with no tasks in it lets you show that you aren’t going to hit that goal this morning.
您可能只剩下顶部切片中的几个任务。现在返回流程并填写缺少的任务以及如果您迟到会做的任务。例如,你可能通常会洗澡,但当你迟到时,你会添加诸如“往脸上泼水”或“用毛巾清洗我身体特别臭的部位”之类的任务。当与一组开发人员一起做这个活动时,我经常看到任务“应用额外的除臭剂”。我不是在评判。我只是说。
You’ll likely be left with just a few tasks in the top slice. Now go back through the flow and fill in tasks that are missing and that you would do if you were late. For example, you might normally take a shower, but when you’re late you instead add in tasks like “Splash water on face” or “Use a washcloth to wash the particularly stinky parts of my body.” When doing this activity with a group of developers, I often see the task “Apply extra deodorant.” I’m not judging. I’m just saying.
这是我的切片地图,用于查找我需要在几分钟内出门的任务。
Here’s my map sliced to find the tasks I’ll need to get out the door in a few minutes.
您可以通过将不同的目标挂在左侧来尝试这个技巧。比如“度过一个最奢华的早晨”或“去度个两周的假期”。您会发现叙事流程保持相当持久,但您需要添加或删除任务以帮助您实现不同的目标。
You can try this trick by thinking of different goals to hang on the left side. Like “Have the most luxurious morning ever” or “Leave for a two-week vacation.” You’ll find the narrative flow stays pretty durable, but that you’ll need to add or remove tasks to help you reach that different goal.
使用切片来识别与特定结果相关的所有任务和详细信息。
Use slices to identify all the tasks and details relevant to a specific outcome.
That was really easy, wasn’t it? As you built this map you learned that:
现在,我很确定你们中的很多人只是在阅读,而不是在阅读时真正映射。别以为我没注意到。但是,如果您是那些没有在早上绘制地图的懒鬼之一,请向我保证您会尝试一下。毫无疑问,这是我最喜欢的教授这些基本绘图概念的方式。如果您是在您的组织中第一次尝试映射,请召集一小群人并完成此练习。你们都将学习基础知识。而且您将能够很好地绘制任何东西。
Now, I’m pretty sure a great number of you were just reading along and not really mapping as you read. Don’t think I didn’t notice. But if you’re one of those slackers who didn’t map your morning, promise me you will try it. It’s hands down my favorite way of teaching these basic mapping concepts. If you’re trying out mapping for the first time in your organization, get a small group of people together and run through this exercise. You’ll all learn the basics. And you’ll be well on your way to being able to map anything.
我怀疑你们中的一些人注意到了这一点,但是您刚刚创建的地图与前四章中创建的地图有根本的区别。Gary、Globo.com、Eric、Mike 和 Aaron 创建的地图都设想了用户在未来将如何使用他们的产品——稍后,在产品交付之后。他们编写了他们想象中人们在产品中所做的任务和活动。但你创建的地图是关于你现在做事方式的地图——事实上,今天早上。而且,事实证明,两者的概念是相同的。所以请放心,我没有浪费你的时间。
I suspect a few of you caught this, but the map you just created has a fundamental difference from the maps created in the first four chapters. The maps Gary, Globo.com, Eric, and Mike and Aaron created all imagine how users will use their products in the future—later, after the product is delivered. They wrote tasks and activities that they imagined people doing in the product. But the map you created is a map about the way you do things now—this morning, as a matter of fact. And, as it turns out, the concepts are the same in both. So be relieved I haven’t wasted your time.
“现在的故事地图”的一个很酷的事情是你可以构建它们来更好地了解人们今天的工作方式。你这样做只是为了了解你今天早上是如何准备的。如果您返回并向地图添加其他内容,您可以了解更多信息。简单的添加是:
One of the cool things about “now story maps” is that you can build them to better understand how people work today. You just did this to learn how you got ready this morning. You can learn even more if you go back and add other things to the map. The easy things to add are:
用户体验社区中的许多人多年来一直在构建这些以更好地了解他们的用户。有时它们被称为旅程地图,但它们的基本思想相同。
Lots of people in the user experience community have been building these for years to better understand their users. Sometimes they’re called journey maps, but they’re the same basic idea.
2000 年代初,我在一家名为 Tomax 的小型产品公司领导团队。我们为实体零售商构建了软件——那些我们在把所有时间都花在网上之前经常去的购物场所。我们接待了一位经营大型油漆和室内装饰连锁店的新客户。现在,我们对零售业以及在销售点销售商品和管理库存的用户了解颇多,但有些事情我们并不知道,这些事情是油漆和装饰店特有的。例如,我们不知道如何销售定制有色油漆或定制百叶窗。我们必须快速学习。
In the early 2000s, I led a team at a small product company called Tomax. We built software for brick-and-mortar retailers—those shopping places we used to go to before spending all our time online. We’d taken on a new customer that ran a large chain of paint and interior decoration stores. Now, we knew quite a bit about retail—and about the users who sold things at point of sale and managed inventory—but there were some things we didn’t know that were specific to paint and decor stores. For instance, we didn’t know how to sell custom-tinted paint or custom blinds. And we had to learn fast.
为了帮助我们学习,我们请求这三位女士的帮助。他们不是软件人。他们是为需要我们软件的公司工作的室内装饰师。从他们那里,我们了解了销售定制百叶窗的来龙去脉。为了快速学习,我们让他们回想上次销售定制百叶窗的情景。我们要求他们写下他们所做的一切——从客户联系他们的那一刻起,直到百叶窗安装完毕并且客户满意为止。现在这听起来应该很熟悉,因为我们要求他们做与您刚才一样的事情来绘制您的早晨——而且几乎是一样的。他们可以说出他们为销售定制百叶窗所做的工作,就像您可以说出自己的名字一样容易早上做准备。而且,当我们组织他们的任务时,我们都知道没有任何一种方法可以做事,他们每个人做事的方式不同或顺序不同。如果您与一小群不同的人一起尝试早上起床地图,您会看到同样的事情。
To help us learn, we asked for the help of these three ladies. They’re not software people. They’re interior decorators working for the company that wanted our software. From them we learned the ins and outs of selling custom blinds. So that we could learn quickly, we asked them to think back to the last time they sold custom blinds. We asked them to write down everything they did—from the moment a customer contacted them, until the moment the blinds were installed and their customer was happy. Now that should sound familiar, because we asked them to do the same thing you just did to map your morning—and it went pretty much the same way. They could name what they did to sell custom blinds as easily as you could name what you did to get ready in the morning. And, when we organized their tasks, we all learned that there wasn’t any one way to do things, that they each did things differently or in a different order. You’ll see the same thing if you try the getting-up-in-the-morning map with a small group of different people.
从这个简单的讲故事和绘图活动中,我们都对他们现在的工作方式建立了共同的理解。正是从这里开始,我们可以开始将这张地图转化为他们需要在我们以后创建的软件中做的事情。
From this simple storytelling and mapping activity, we all built shared understanding of how they worked now. It was from here that we could begin to translate this map into the things they’d need to do in the software we’d create later.
我不会骗你的。如果您是一名软件专家,您可能需要一段时间才能停止谈论功能和屏幕,并开始编写简短的动词短语来说明人们真正想做的事情。保持练习。你会明白的。
I won’t lie to you. If you’re a software professional, it may take you a while to stop talking about features and screens, and to start writing short verb phrases that say what people are really trying to do. Keep practicing. You’ll get it.
如果您不确切地知道您的用户是谁、她想要完成什么或她如何去做,这将非常困难。可悲的是,在这种情况下尝试构建地图只会指出您不知道的内容。如果那是你所在的地方,那么你将需要更多地了解人们以及他们所做的事情。更好的是,直接与他们合作创建地图。
This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it. Sadly, trying to build a map in this situation will just point out what you don’t know. If that’s where you are, then you’ll need to learn more about people and what they do. Better yet, work with them directly to create a map.
绘制地图可以帮助您看到全局,只见树木不见森林。这是故事地图的最大好处之一。但是,如果您是负责建造森林的人,则需要一次建造一棵树。您已经了解了让故事发挥作用的两个最重要的因素:
Building a map helps you see the big picture, to see the forest for the trees. That’s one of the biggest benefits of story mapping. But if you’re the one responsible for building the forest, you’ll need to do it one tree at a time. You’ve already learned the two most important things that make stories work:
记住这些事情,随着你的前进,一切都会水到渠成。
Keep these things in mind, and everything will fall into place as you go forward.
现在是我们讨论“逐树”使用故事的一些策略的时候了,因为很多地方都可能出错,而且要很好地使用故事,您还需要了解一些其他事项。
It’s time we talked about some of the tactics for using stories “tree by tree,” because a lot can go wrong, and there are a few more things you need to know to use stories well.
[ 8 ]封面故事是戴夫·格雷 (Dave Gray) 等人在《游戏风暴》( Gamestorming ) 一书中发现的众多优秀实践之一。(奥莱利)。
[8] Cover Story is one of the many great practices found in the book Gamestorming by Dave Gray, et al. (O’Reilly).
故事地图是一个非常简单的想法。使用简单的地图,您可以与他人一起讲述产品故事,并像您一样查看大图。然后,您将大局剖析以做出良好的规划决策。在这一切之下是敏捷故事的简单概念。
Story mapping is a remarkably simple idea. Using a simple map, you can work with others to tell a product’s story and see the big picture form as you do. Then, you carve up that big picture to make good planning decisions. Underneath all that is the simple concept of Agile stories.
故事的想法起源于一个名叫肯特贝克的非常聪明的人。上世纪 90 年代后期,Kent 与其他人一起从事软件开发,他注意到软件开发中最大的问题之一源于使用文档来精确描述我们想要的东西(即需求)的传统过程方法。现在你知道问题所在了。不同的人可以阅读同一份文件并想象不同的事物。他们甚至可以在文档上“签字”,相信他们已经达成一致。
The idea of stories originated with a very smart guy by the name of Kent Beck. Kent was working with other people on software development in the late ’90s, and he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want—that is, the requirements. By now you know the problem with that. Different people can read the same document and imagine different things. They can even “sign off” on the document believing they’re in agreement.
后来,当我们深入开发软件时——甚至比这更晚,在软件交付之后——我们才意识到我们在考虑不同的事情。许多人将这种缺乏共同理解的情况称为“糟糕的需求”。
It’s later, when we get into the thick of developing software—or even later than that, after it’s delivered—that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”
让我在这里发泄一下。我很高兴与许多团队合作。我们经常通过谈论他们面临的最大挑战来开始合作。而且,毫无疑问,我听到最多的是“糟糕的要求”。然后每个人都指着那个文件。文档编写者感觉很糟糕——好像他应该多写或少写,或者使用一些很酷的需求技术。那些签字的人先是难过,然后是义愤填膺。“你肯定没想到我会阅读每一个细节!毕竟,我们已经讨论了好几天了。我只是希望你能理解我说的话。反正我也看不懂你那愚蠢的需求文档。” 构建软件的人感到措手不及。他们糊里糊涂地浏览了那些神秘的文件,但他们构建的东西仍然是错误的。每个人最终都讨厌这份文件。
Let me vent a minute here. I have the pleasure of working with lots of teams. And we often start work together by talking about their biggest challenges. And, hands down, the one I hear most is “bad requirements.” And then everyone points at that document. The document writer feels bad—as if he should have written more, or less, or used some cool requirements technique. Those who signed off feel bad at first, and then indignant. “Surely you didn’t expect I’d read every detail! After all, we talked about this for days. I just expected you’d understood what I said. I can’t understand your silly requirements document anyway.” And the people building the software feel blindsided. They muddled their way through those cryptic documents and what they built was still wrong. Everyone hates the document in the end. Yet we still keep trying to write a better one.
我们可以同时阅读同一份文件,但对它有不同的理解。
We can both read the same document, but have a different understanding of it.
但误解文档只是问题的一半。我们浪费了大量的时间和金钱来构建文档描述的内容,后来才发现真正解决预期问题的方法是非常不同的。你没听错。这些文件往往准确地描述了错误的事情。文档通常会描述我们需要什么,但不会描述我们为什么需要它。如果构建软件的人可以简单地与了解将使用该软件的用户以及他们为什么使用它的人交谈,通常会有一种更具成本效益的方式来取悦这些用户。不说话,我们就永远不知道它。
But misunderstanding the document is only half the problem. We waste lots of time and money building what the document describes, only to find out later that what actually solves the intended problem is something very different. You heard me right. Those documents often accurately describe the wrong thing. Documents usually describe what we need, but not why we need it. If the person building software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users. Without talking, we just never know about it.
最好的解决方案来自需要解决问题的人和能够解决问题的人之间的协作。
The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.
肯特的简单想法是阻止它——停止如此努力地编写完美的文档,并聚在一起讲故事。故事的名字不是来自它们应该如何编写,而是来自它们应该如何被使用。让我更加激动地重复一遍。现在你应该停止你正在做的任何事情并大声说出来:
Kent’s simple idea was to stop it—to stop working so hard on writing the perfect document, and to get together to tell stories. Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Let me repeat that with more emotion. Right now you should stop whatever you’re doing and say this out loud:
故事的名字来自于它们应该如何被使用,而不是来自于你试图写下的内容。
Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.
肯特的想法很简单。如果我们聚在一起讨论我们正在用软件解决的问题,谁会使用它,为什么,那么我们就可以一起找到解决方案,并在此过程中建立共同的理解。
Kent’s idea was simple. If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.
不久前,我开始注意到整个故事有点偏离方向了;也就是说,许多写书、教学和使用书籍的人都专注于写故事的活动。如果每次有人问我如何写好故事时我都能得到一毛钱,我得到的毛钱会比几章前收集到的还要多。
A while back I began to notice that this entire story thing had gone a bit sideways; that is, lots of the people writing books, teaching, and using them focused on the activity of writing stories. If I had a dime for every time I’ve been asked how to write good stories, I’d have even more dimes than I collected a few chapters ago.
我全神贯注于写故事,然后回到肯特,以确保我没有遗漏任何东西。在电子邮件对话过程中,肯特解释了这个想法的来源:
With all the focus on writing stories, I went back to Kent to make sure I wasn’t missing something here. Over the course of an email conversation, Kent explained where the idea came from:
我在想的是用户有时会讲述他们使用的软件所做的很酷的新事物的故事。[例如,] 如果我输入邮政编码,它会自动填写城市和州,而无需我触摸按钮。
我认为这是触发这个想法的例子。如果您可以讲述有关软件功能的故事并在听众的脑海中产生兴趣和愿景,那么为什么不在软件执行之前讲故事呢?
— Kent Beck 通过个人电子邮件,2010 年 8 月
What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button.
I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?
— Kent Beck via personal email, Aug 2010
所以这个想法是有说服力的,如果你在听众的脑海中产生能量、兴趣和愿景,你就知道你做对了。那很大。而且这听起来比阅读典型的需求文档有趣得多。[ 9 ]
So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.[9]
但是那些开始使用故事进行软件开发的人——以及他们头脑中仍然保留着传统过程模型的人——往往会专注于写作部分。我见过团队用写故事取代他们的传统需求流程,然后在尝试写故事来准确传达应该构建的内容时感到沮丧。如果您现在正在这样做,请停止。
But folks who start using stories for software development—and who still have a traditional process model in their heads—tend to focus on the writing part. I’ve seen teams replace their traditional requirements process with story writing, and then get frustrated trying to write stories to precisely communicate what should be built. If you’re doing that now, stop it.
如果您没有聚在一起就您的故事进行丰富的讨论,那么您就没有真正使用故事。
If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.
在《Extreme Programming Installed 》一书中,Ron Jeffries 等人。(Addison-Wesley Longman Publishing) 描述最好的故事过程:
In the book Extreme Programming Installed, Ron Jeffries et al. (Addison-Wesley Longman Publishing) describe the story process best:
如果这听起来很简单,那是因为它确实如此。请记住,简单并不容易。
If it sounds simple, it’s because it is. Just remember, simple isn’t easy.
想象一下,您负责与团队合作构建一些软件。尽你所能想象那个软件。然后,针对用户想用产品做的每一件事,写一张卡片。你最终会得到一堆。肯特最初的想法是将它们写在索引卡片上,因为在桌面上整理一堆卡片很容易。更容易确定它们的优先级,或者将它们组织成一个结构,以帮助您看到全局——当然是像故事地图这样的结构。
Imagine you’re responsible for working with a team to get some software built. Imagine that software as best you can. Then, for each thing users want to do with the product, write a card. You’ll end up with a bunch of them. Kent’s original idea was to write them on index cards because it’s easy to organize a bunch of cards on a tabletop. It’s easier to prioritize them, or organize them into a structure that helps you see the big picture—a structure like a story map, of course.
描述整个产品或我们想要对现有产品进行的所有更改的一堆卡片称为产品积压。该术语起源于敏捷过程 Scrum。我认识的人曾经说过,“我讨厌积压这个词。我们甚至还没有开始构建软件,听起来我们已经落后了!” 我不确定我对那一堆故事有更好的名字,但如果你能想到一个好的名字,请使用它,并让我知道它是什么。
The bunch of cards that describes the whole product, or all the changes we’d like to make to a product we have, is called a product backlog. That term originated with the Agile process Scrum. Someone I know once said, “I hate that term backlog. We haven’t even started to build software, and it already sounds like we’re behind!” I’m not sure I have a better name for that bunch of stories, but if you can think of a good one, please use it, and let me know what it is.
谈话可能从你描述你的想法开始,倾听的人可能会根据她听到的内容在她的脑海中形成一个想法。因为很难完美地解释事情,而且因为根据我们过去的经验很容易想象出不同的东西,所以听众可能想象出与你不同的东西。但这就是魔法的用武之地。
The conversation might start with you describing what you’re thinking, and the person listening might form an idea in her head based upon what she heard. Because it’s hard to explain things perfectly, and because it’s easy to imagine different things based on our past experience, the listener likely imagined something different than you. But that’s where the magic comes in.
因为这是一次对话,所以听众可以提出问题,来回提问可以纠正这种理解并帮助每个人达成某种共识。
Because this is a conversation, the listener can ask questions and it’s the back and forth that will correct that understanding and help everyone arrive at some shared understanding.
在传统的软件过程中,有需求的人的目标是将它们正确地写下来;对于要构建软件的人来说,就是要正确理解它们。因为这是一个故事驱动的过程,所以你们每个人都有不同的共同目标。你们的目标是共同努力,了解构建软件所要解决的问题,并尽最大努力解决它。最终,您需要就应该构建的内容达成一致,双方都认为这会对产品的用户有所帮助。
In a traditional software process, the goal for the person who had the requirements is to get them written down correctly; and for the person who’s going to build the software, it’s to understand them correctly. Because this is a story-driven process, you each have a different shared goal. Your goal is to work together to understand the problem being solved by building software, and solve it as best you can. Eventually, you’ll need to agree on what you should build that you both believe will help the users of the product.
让我再说一遍,因为这是很重要的一点:
Let me say this again, because it’s an important point:
故事对话是关于共同努力为我们都理解的问题找到最佳解决方案。
Story conversations are about working together to arrive at a best solution to a problem we both understand.
所有这些谈话都很酷,但我们最终必须构建一些软件——对吧?所以,当我们觉得我们正在汇聚一个好的解决方案时,我们需要开始关注这些问题的答案:
All this talking is cool, but we’ve eventually got to build some software—right? So, when we feel like we’re converging on a good solution, we’ll need to start focusing on the answer to these questions:
达成这项协议的途径不仅仅是一张牌和大量的挥手。如果对话包含很多内容,例如简单的人物角色、工作流程图、UI 草图和任何其他有助于解释事情的传统软件模型,那么对话会进行得最好。这样,您不必只是挥手——您也可以指指点点。无论我们将什么带入对话,我们都会进行标记、书写、更正和更改。在那次谈话中,我们甚至会当场创造很多东西。使用白板或活动挂图纸。并且在您离开之前不要忘记拍摄一些“假期照片”。您创建的内容的照片将帮助您回忆起难以写下的对话的所有细节。
The path to get to this agreement isn’t just a single card and lots of hand waving. The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too. Whatever we bring into the conversation we’ll mark up, write on, correct, and change. We’ll even create a lot of things on the spot during that conversation. Use a whiteboard or flipchart paper. And don’t forget to take some “vacation photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.
好的故事对话有很多文字和图片。
Good story conversations have lots of words and pictures.
在谈话中保持你决定的验收标准大而显眼。这个团队使用活动挂图纸边走边记录。
Keep the acceptance criteria you decide on big and visible during the conversation. This team uses flipchart paper to record as they go.
仅此而已。这是肯特颠覆性的简单想法。而且,如果你这样做,我向你保证它会改变一切。
That’s all there is. That’s Kent’s disruptively simple idea. And, if you do it, I promise you it’ll change everything.
除非没有。
Unless it doesn’t.
对于习惯于以老式方式工作的人来说,这种对话可能会非常糟糕。他们又回到了他们带来东西的人的旧模式,努力工作以准确地向对方传达他想要的东西,而另一个人则努力尝试理解并在对方说的话上打孔. 如果这样持续太久,他们往往会有互相戳洞的感觉,不利于事情的完成。
For people used to working the old-fashioned way, this conversation can go really badly. They fall back into their old patterns of the person bringing in stuff, trying to work hard to communicate exactly what he wants to the other person, and the other person working hard to try to understand and then punch holes in what the other person is saying. If this goes on too long, they often feel like punching holes in each other, which is not conducive to getting things done.
有一些事情要记住,以帮助这些对话进行得更好。令人高兴的是,这就是下一章的内容。
There are some things to keep in mind to help these conversations go better. Happily, that’s what the next chapter is about.
故事的想法很简单。也许太简单了。对于很多软件开发人员来说,像这样的对话感觉很陌生……而且有点不舒服。人们经常像往常一样谈论需求。
The idea of stories is simple. Maybe too simple. For lots of people in software development, conversations like these feel very foreign…and a little uncomfortable. And people often revert to talking about requirements like they always used to.
当 Kent Beck 最初描述故事的概念时,他并没有称它们为用户故事,他只是称它们为故事——因为那是他希望你讲的。但是在第一本关于极限编程发表了,故事选择了更具描述性的前缀用户,这样我们就可以记住从软件之外的人的角度进行对话。然而,更改名称还不够。
When Kent Beck originally described the idea of stories, he didn’t call them user stories, he just called them stories—because that’s what he hoped you’d be telling. But very soon after the first books on Extreme Programming were published, stories picked up the more descriptive prefix user so that we’d remember to have conversations from the perspective of the people outside the software. Changing the name wasn’t enough, however.
This is my friend Rachel Davies. And she’s holding a story card.
1990 年代后期,她在一家名为 Connextra 的公司工作。Conntextra 是极限编程的最早采用者之一,极限编程是故事的来源。当 Connextra 的人们开始使用故事时,他们发现他们遇到了一些常见的问题。在 Connextra 撰写故事的大多数人来自销售和市场营销部门。他们倾向于写下他们需要的功能。但是,当开发人员需要进行对话时,他们需要找到最初的利益相关者并开始良好的对话——包括谁和为什么。仅仅知道功能的名称并不能帮助团队找到合适的人与之交谈或开始正确的讨论。而且,那时候,没有太多关于卡片上可以或应该包含什么的指导。Connextra 的模板随着时间的推移而演变。这不是雷切尔特意发明的。相当,
In the late 1990s she worked for a company called Connextra. Conntextra was one of the earliest adopters of Extreme Programming, the Agile process where stories came from. When the Connextra folks started using stories, they found they ran into some common problems. Most of the people who wrote the stories at Connextra were from sales and marketing. They tended to write down the feature they needed. But, when it came time for developers to have conversations, they needed to find that original stakeholder and get a good conversation started—one that included who and why. Just having the name of the feature wasn’t helping the team find the right people to talk to, or to start the right discussions. And, back then, there wasn’t much guidance about what could or should be on a card. The template evolved over time at Connextra. It wasn’t Rachel’s invention specifically. Rather, it was the entire organization’s desire to build things that mattered.
使用该模板一段时间后,Connextra 的人们想炫耀一下他们很酷的新技巧。他们打印了一堆示例卡片,以在 XPDay 2001(伦敦的一个小型会议)上炫耀。这就是雷切尔手里拿着的东西。这是她的最后一张牌,很可能是现存的最后一张牌,所以这使它成为历史文物。
After using the template for a while, the folks at Connextra wanted to show off their cool new trick. They printed a bunch of example cards to show off at XPDay 2001, a small conference in London. That’s what Rachel is holding. It’s her last card, and might very well be the last card in existence, so that makes it a historical artifact.
模板是这样的:
The template goes like this:
作为[用户类型]
我打算做点什么]
这样我就可以[得到一些好处]
As a [type of user]
I want to [do something]
So that I can [get some benefit]
Connextra 的人们使用这个简单的模板来编写他们故事的描述。请注意,他们的故事仍然有简短而有用的标题。他们发现,多写一点点来开始讲述故事会迫使他们停下来思考:谁、什么以及为什么。而且,如果他们不知道,他们可能会质疑他们是否应该写这个故事。
The folks at Connextra used this simple template to write the descriptions of their stories. Note that their stories still have short, useful titles. They found that writing this little extra bit to start to tell the story forced them to pause and think about: who, what, and why. And, if they didn’t know, they might question whether they should be writing the story at all.
当他们坐下来讨论故事时,他们会拿起那张卡片,然后阅读描述。这个描述开始了谈话。
When they sat down to have the story conversation, they’d pick up that card and then read that description. That description started the conversation.
使用简单的故事模板开始对话。
Use the simple story template to start conversations.
如果您在故事地图之外拿起一张单独的卡片,模板是启动对话的好方法。请记住,在第 1 章中,Gary 地图正文中的一张卡片上写着“上传图像”。该卡片是“自定义我的促销传单”卡片下的详细信息之一。我在地图卡片上写的是那些简短的动词短语——用户使用我的软件执行的任务。但是当我自己拿起一个时,我将需要在地图中描述的用户大旅程中间拿起故事。我可能会说:
If you’re picking up an individual card outside of a story map, the template is a good way to boot up the conversation. Remember in Chapter 1 that one of the cards in the body of Gary’s map said, “Upload an image.” And that card was one of the details under the card “Customize my promo flyer.” What I write on the cards in a map are those short verb phrases—the tasks the users are performing with my software. But when I pick one up by itself, I’ll need to pick up the story in the middle of the user’s big journey described in the map. I might say:
“作为乐队经理,我想上传一张图片,以便定制我的宣传传单。”
“As a band manager, I want to upload an image so that I can customize my promo flyer.”
这是一个很酷的把戏。我可以找到挂在地图上方的不同用户的卡片,而用户更大的目标往往就在你随时查看的卡片上方的卡片中。
That’s a pretty cool trick. I can find the cards for different users hanging above the map, and the users’ bigger goal is often in the card above the one you’re viewing at any one time.
但请记住——这只是一个话题的开场白。而且,事实上,对话可能会像这样继续:
But remember—it’s just a conversation starter. And, in fact, the conversation might continue like this:
“乐队经理为什么要定制传单?”
“嗯,因为它不会自动在上面放上他乐队的照片,而他希望它放在那里。而且他非常关心原创——他不希望它看起来像其他人的一样。”
“这就说得通了。像乐队经理这样的人把这些照片放在哪里?”
“嗯,他们到处都是,真的。它们可能在本地硬盘上、Flickr 帐户中或网络上的其他地方。”
“嗯……这和我原本想的不一样。我以为他们只是在他们的硬盘上。”
“不,我们采访过的很多人都让他们遍布各地。这有点问题。”
“Why would the band manager want to customize the flyer?”
“Well, because it won’t have his band’s photo on it automatically, and he’d want it to be there. And he cares a lot about being original—he wouldn’t want it to look like everyone else’s.”
“That makes sense. Where do people like band managers keep those photos?”
“Well, they’re all over the place, really. They may be on their local hard drives, in Flickr accounts, or in other places on the Web.”
“Hmm…that’s different than I was originally thinking. I assumed they’d just be on their hard drives.”
“No, lots of the people we’ve talked to have them spread all over the place. It’s kind of a problem.”
事实上,我和加里的很多谈话都是这样进行的。在我们谈话时,我们会在白板上或卡片上写下一些东西。不久之后,我们就会草拟想法。
In fact, a lot of the conversation I had with Gary went like that. As we were talking, we’d write something down on a whiteboard or on the card itself. Before too long we’d be sketching ideas.
您可以看到非常短的模板不足以成为规范。但是,当我们使用该模板开始对话时,我们最终会进行比仅仅谈论文件上传器更丰富的对话。
You can see that the very short template isn’t nearly enough to be the specification. But when we start a conversation using that template, we end up in a much richer conversation than if we’d just talked about a file uploader.
术语模板僵尸来自Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior一书汤姆德马科等人。(多塞特之家)。这个名字说明了一切,但我会给你作者的定义:
The term template zombies comes from the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco et al. (Dorset House). The name says it all, but I’ll give you the authors’ definition:
模板僵尸:
项目团队允许其工作由模板驱动,而不是由交付产品所需的思维过程驱动。
Template Zombie:
The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.
就像那个模板一样简单,它被滥用了很多。我看到人们真的很难在不合适的时候将想法强加到模板中。有关后端服务或安全问题的故事可能具有挑战性。我看到人们从自己的角度写作和思考事情,而不是最终受益者的角度:“作为产品负责人,我希望你构建一个文件上传器,以满足客户的需求。” 诸如此类的讨厌的事情。
As simple as that template is, it gets abused quite a bit. I see people really struggle to force ideas into the template when they just don’t fit. Stories about backend services or security issues can be challenging. I see people writing and thinking about things from their own perspective, not that of the people who ultimately benefit: “as a product owner, I want you to build a file uploader so that the customer requirements are met.” Nasty things like that.
更糟糕的是,模板已经变得如此普遍,并且被普遍教导,以至于有些人认为如果不是以这种形式编写的,就不是一个故事。许多人甚至不再在故事中使用标题,而是在每张卡片上只写下那句长话。想象一下,尝试阅读以这种方式编写的故事列表。想象一下,尝试使用故事地图向某人讲述一个故事,其中每个便签都是这样写的。这对大脑来说很难。
Even worse, the template has become so ubiquitous, and so commonly taught, that there are those who believe that it’s not a story if it’s not written in that form. Many people have even quit using titles on stories and write only that long sentence on every single card. Imagine trying to read through a list of stories written that way. Imagine trying to tell someone a story using a story map where every sticky is written that way. It’s tough on the brain.
这一切都让我很难过。因为故事的真正价值不在于卡片上写的内容。它来自我们讲故事时学到的东西。
All of this makes me sad. Because the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.
它不需要写在模板中就可以被视为故事。
It doesn’t need to be written in a template to be considered a story.
这张照片中的人正在学习滑雪。[ 10 ]如果你曾经学过滑雪,并且有人在教你,你就会做这个人正在做的事情。它被称为扫雪机。在这里,您可以将滑雪板的尖端放在一起并靠在滑雪板的内侧边缘上。当你的脚上夹着两块滑板时,这是控制速度和保持直立的最简单方法。这是我推荐的学习滑雪的方式。但这不是最佳实践,而是最佳学习实践。没有奥林匹克扫雪机比赛。你酷炫的扫雪机姿势不会给斜坡上的任何人留下深刻印象。不过,这没什么好尴尬的。如果人们看到你那样滑雪,他们就会知道你在学习。
The person in this picture is learning to ski.[10] If you’ve ever learned to ski, and someone helpful is teaching you, you’ll do what this person is doing. It’s called a snowplow. It’s where you put the tips of your skis together and lean on the inside edges of your skis. It’s the easiest way to control your speed and stay upright when you’ve got two slippery boards clamped to your feet. It’s the way I’d recommend learning to ski. But it’s not best practice—it’s a best learning practice. There’s no Olympic snowplow event. You won’t impress anyone on the slopes with your cool snowplow stance. It’s nothing to be embarrassed of, though. If people see you skiing that way, they’ll know you’re learning.
对我来说,故事模板有点像学习扫雪机。用它来写你的第一个故事的描述。大声说出来开始你的故事对话。但是,如果您发现它并不总是有效,请不要太担心。就像滑雪者的扫雪技术一样,它不是困难地形的最佳选择。
For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories. Say it aloud to start your story conversations. But don’t get too concerned if you find that it doesn’t always work. Just like the snowplow technique for skiers, it’s not the best choice for difficult terrain.
我最喜欢的模板:如果我在便利贴或卡片上写故事,它们不会放在更大的故事地图中,我先给他们一个简短的标题,然后在标题下面写下:
My favorite template: if I’m writing stories on sticky notes or cards, and they won’t be sitting inside a bigger story map, I’ll first give them a short, simple title, and then under it I’ll write:
谁:
什么:
为什么:
Who:
What:
Why:
而且我会在每行之间给出几行,因为我想具体说出所有不同的人,说一下是什么,并记下不同的原因。当我们开始谈论这些故事时,我想在卡片上留出空间来添加额外的信息。当人们在卡片中间写标题时,这实际上是我的一个小毛病,因为当我们开始谈话时,我没有任何空间做笔记。但我就是那样挑剔。
And I’ll give a couple of lines in between each, because I’ll want to specifically name all the different whos, say a little about the what, and make notes about the different reasons why. I’ll want to leave room on the card to add extra information when we start talking about the stories. It’s actually a pet peeve of mine when people write the title in the middle of the card, because it doesn’t leave me any room to make notes when we start talking. But I’m nitpicky that way.
请不要只谈论“用户”。请明确点。谈谈你指的是哪个用户。对于 Gary,他可以谈论乐队经理或音乐迷。
谈论不同类型的用户。对于许多软件,尤其是消费类软件,使用相同功能的用户类型多种多样。从不同用户的角度谈论功能。
谈论客户。对于消费品,客户(或选择者)可能与用户是同一个人。但对于企业产品,我们需要讨论做出购买决定的人、他们的整个组织以及他们如何受益。
谈谈其他利益相关者。谈论赞助软件购买的人。谈论可能与用户合作的其他人。
很少只有一个用户很重要。
Please don’t just talk about “the user.” Be specific. Talk about which user you mean. For Gary, he could talk about the band manager or the music fan.
Talk about different types of users. For many pieces of software, especially consumer software, there are very diverse types of users using the same functionality. Talk about the functionality from different users’ perspectives.
Talk about the customers. For consumer products, the customer (or chooser) may be the same person as the user. But for enterprise products, we’ll need to talk about the people who make buying decisions, their organization as a whole, and how they benefit.
Talk about other stakeholders. Talk about the people sponsoring the software’s purchase. Talk about others who might collaborate with users.
There’s rarely just one user who matters.
谈谈为什么特定用户关心。并深入挖掘“为什么”,因为通常有几个,而且它们是分层的。您可以长时间“用为什么坚持戳它”,以真正了解背后的原因。
谈谈为什么其他用户关心。谈谈为什么用户的公司关心。谈谈为什么业务利益相关者关心。为什么里面隐藏着很多伟大的东西。
Talk about why the specific user cares. And dig deeply into the “whys,” because there are often a few, and they’re layered. You can keep “poking it with the why stick” for a long time to really get at the underlying reasons why.
Talk about why other users care. Talk about why the user’s company cares. Talk about why business stakeholders care. There are lots of great things hidden inside why.
如果您谈论所有这些事情,您可能偶然发现了一些您不知道的事情。确定您的问题并讨论在构建软件之前获得答案的重要性。决定由谁来跑腿来回答这些问题,并将它们带回您的下一次对话。你会发现需要大量的对话来思考一些故事。
花时间质疑你的假设。你真的了解你的用户吗?这真的是他们想要的吗?他们真的有这些问题吗?他们真的会使用这个解决方案吗?
质疑您的技术假设。我们依赖哪些底层系统?他们真的像我们想的那样工作吗?是否存在我们需要考虑的技术风险?
所有这些问题和假设可能需要经过深思熟虑才能解决或学习。制定一个计划来做到这一点。
If you talk about all those things, you’ve likely stumbled across something you don’t know. Identify your questions and discuss how important they are to get answered before you build software. Decide who’ll do the legwork to get those questions answered, and bring them back to your next conversation. You’ll find it takes lots of conversations to think through some stories.
Take time to question your assumptions. Do you really understand your users? Is this really what they want? Do they really have these problems? Will they really use this solution?
Question your technical assumptions. What underlying systems do we rely on? Do they really work the way we think? Are there technical risks we need to consider?
All these questions and assumptions may require deliberate work to resolve or learn. Make a plan to do just that.
当故事对话中的那些人放弃一些关于解决方案应该是什么的原始假设时,真正的大胜利就来了,回到他们试图解决的问题,然后一起得出一个更有效、更经济的解决方案。
The really big win comes when those in a story conversation discard some original assumptions about what the solution should be, go back to the problem they’re trying to solve, and then together arrive at a solution that’s more effective and more economical to build.
坐在故事对话中时,我经常听到有人焦急地说:“我们应该谈论什么,而不是如何!” 他们的意思是我们应该讨论用户需要做什么,而不是应该如何编写代码。当我们谈论“什么”而不谈论“为什么”时,我也感到同样的焦虑。但事实是,我们正试图在一个好的故事对话中针对所有这三个方面进行优化。出问题的是任何一方都认为特定的解决方案或其实施方式是“要求”。如果不明确谈论如何(如果您是开发人员,我知道您正在考虑),就很难考虑解决方案的成本。因为,如果解决方案太昂贵,那么它可能不是一个好的选择。
在谈话中尊重他人的专业知识。不要告诉训练有素的技术人员如何做她的工作。不要告诉非常熟悉用户及其工作的人他不理解的地方。提出问题,真诚地尝试相互学习。
When sitting in a story conversation, I often hear someone anxiously say, “We should be talking about the what, not the how!” By that they mean we should be talking about what users need to do, not how the code should be written. And I feel the same anxiousness when we talk about the “what” without talking about the “why.” But the truth is, we’re trying to optimize for all three in a good story conversation. What goes wrong is when either party assumes that a particular solution or the way it’s implemented is a “requirement.” Without explicitly talking about how (and if you’re a developer, I know you’re thinking about it), it’s difficult to think about the cost of the solution. Because, if a solution is too expensive, then it may not be a good option.
Be respectful of the expertise of others in the conversation. Don’t tell a highly trained technical person how to do her work. Don’t tell someone intimately familiar with users and their work that he doesn’t understand. Ask questions, and genuinely try to learn from each other.
最终,我们需要做出一些决定来继续构建或不构建某些东西。在没有价格标签的情况下很难做出这种购买决定。
对于软件,这通常意味着编写代码需要多长时间。在早期的对话中,这可能会被表达为“很长一段时间”或“几天”。更好的是将它与已经构建的东西进行比较——“与我们上个月构建的评论功能大致相同。” 随着我们越来越接近构建某些东西,并且我们进行了更多的对话并做出了更多的决定,我们将能够更加精确。但我们始终知道我们在这里谈论的是估计,而不是承诺。
Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag.
For software, that usually means how long it’ll take to write the code. In early conversations, that might be expressed as “a really long time” or “a few days.” Even better is comparing it to something already built—“about the same as that feature for commenting we built last month.” As we get closer to building something, and we’ve had more conversations and made more decisions, we’ll be able to be a bit more precise. But we always know we’re talking about estimates here, not commitments.
因为有很多话要谈,而且你不想忘记,所以确保您正在记录特定的事情,以帮助您记住您所做的决定,或者您需要研究的问题和假设。不要忘记将您的想法外化,以便讨论中的其他人可以看到记录的内容。
Because there’s a lot to talk about, and you won’t want to forget it, make sure you’re recording specific things that help you remember the decisions you made, or the questions and assumptions you’ll need to look into. Don’t forget to externalize your thinking so that others in the discussion see what’s recorded.
如果你写下来了,你可以拿起来以后参考。如果它贴在墙上,您只需指向它即可。而且,如果你们作为一个团队一起交谈,您会发现不必如此频繁地重复所有内容,因为人们会记住——尤其是如果您用简单的图画和文件……那些度假照片来固定你们的谈话。
If you write it down, you can pick it up and refer to it later. If it’s posted on the wall, you can just point at it. And, if you’re talking together as a team, you’ll find you won’t have to repeat everything so often, because people will remember—especially if you anchored your conversations with simple drawings and documents…those vacation photos.
这个小组正在进行故事讨论。在他们交谈时,他们将自己的想法形象化,并对他们的决定做笔记。
This small group is having a story discussion. As they talk, they visualize their ideas and make notes about what they decide.
我最喜欢的方法是做他们正在做的事情。我们谈话时,我会在活动挂图纸或白板上记录下来。我喜欢直接在黑板上记下谁在对话中,然后在完成后给黑板拍照。我将使用 wiki 或其他工具共享照片。我知道我可以在以后需要时提取细节或更正式地写下它们。如果我不记得确切说了什么,谈话中的其中一个人可能会记得。幸好我把他们的名字写下来了。
My favorite approach is to do exactly what they’re doing. I record on flipchart paper or a whiteboard as we talk. I like making a note of who was in the conversation directly on the board, and then photographing the board when I’m done. I’ll share the photo using a wiki or other tool. I know I can extract details or write them up more formally when I need them later. If I can’t remember exactly what was said, one of those people in the conversation might. It’s a good thing I wrote their names down.
想想你可以在故事中谈论多少内容是令人生畏的。在这一点上,您可能想回到过去的美好时光,那时您需要做的就是担心理解“需求”。回到真正解决问题不是您的工作的时候。回到你只需要构建你被告知的东西的时候,确保它是正确构建的东西是别人的问题。但我相信你和大多数人都非常喜欢解决问题。所以现在是你的机会。
It’s daunting to think about how much there is you could be talking about in stories. At this point, you may want to go back to the good old days when all you needed to do was worry about understanding the “requirements.” Back when it wasn’t your job to really solve problems. Back when you just needed to build what you were told to, and it was someone else’s problem to make sure it was the right thing to build. But I believe that you, and most people out there, really like solving problems. So now’s your chance.
您可能已经想到,要谈论所有这些事情,就会有很多信息需要跟踪。所有这些东西都放不下便签纸或索引卡。你是对的。它不会。那么让我们接下来谈谈这张卡上真正发生了什么,什么没有发生。
It may have occurred to you that with all these things to talk about, there will be a lot of information to keep track of. And all that stuff isn’t going to fit on a sticky note or an index card. You’re right. It won’t. So let’s talk next about what really does go on that card, and what doesn’t.
是的,主要的想法是卡片上的短篇小说标题将帮助我们计划和促进可以构建软件的人和理解需要用它解决的问题的人之间的大量对话。但是,可悲的是,将完成的软件产品推出市场需要的不仅仅是几个人。
Yes, the big idea was that short story titles on cards would help us plan and facilitate lots of conversations between the people who could build software and the people who understood the problems that needed to be solved with it. But, sadly, it takes more than a couple of people to get a finished piece of software out the door.
在一个典型的团队中,您会发现项目经理、产品经理、业务分析师、测试人员、用户体验设计师、技术作家和我可能忘记的其他一些角色。他们都在看同样的卡片,但他们的谈话会有所不同,因为他们都有不同的关注点要照顾。
On a typical team you’ll find project managers, product managers, business analysts, testers, user experience designers, technical writers, and some other roles I’m probably forgetting. They’re all looking at the same cards, but the conversations they have are going to be different because they’ve all got different concerns to look after.
如果我是产品经理或产品负责人,并且我对这款产品的成功负有责任,那么我必须对我的目标市场有更多的了解。我需要假设有多少人会购买或使用该产品,或者它将如何影响我公司的盈利能力。我想谈谈那些事情。
If I’m a product manager or product owner, and I’m responsible for the success of this product, then I have to know a little more about my target market. I need to form some hypothesis about how many people will buy or use this product, or how it’s going to affect the profitability of my company. I’ll want to talk about those things.
如果我是一名业务分析师,我可能会深入研究很多细节,所以我需要了解用户界面中正在发生的事情,以及用户界面背后的系统中的业务规则。
If I’m a business analyst, I might be diving into a lot of details, so I need to understand what’s going on in the user interface, and the business rules in the system that are behind the user interface.
如果我是一名测试人员,我需要考虑软件可能在哪些方面出现故障。我需要进行一些对话来帮助我制定一个好的测试计划。
If I’m a tester, I need to think about where the software is likely to fail. I need to have some conversations to help me put together a good test plan.
如果我是一名 UI 设计师,我不想被告知 UI 是什么样子,就像开发人员不想被告知代码应该如何编写一样。我想知道谁在使用它,为什么以及他们在做什么,这样我就可以设计一个有用且可用的用户界面。
If I’m a UI designer, I don’t want to be told what the UI looks like any more than a developer wants to be told the way the code should be written. I’ll want to know who’s using it, and why and what they’re doing, so I can design a useful and usable user interface.
最后,如果我是负责协调这群人的项目经理,我将不得不注意他们在讨论所有这些细节时做出决定。当它开始时,我需要注意依赖关系、时间表和开发状态。
Finally, if I’m a project manager responsible for coordinating this group of people, I’ll have to pay attention when all of them are talking to make decisions about all these details. I’ll need to pay attention to dependencies, schedules, and the status of development when it gets started.
这是很多对话。其中一些必须先于其他发生。而且其中许多发生不止一次。因此,为了使其准确,我们可能必须在 3个C中再添加十几个C。但令人高兴的是,如果你们真的在一路上进行对话并建立共同的理解,你就会避免很多误解和路线更正。
That’s a lot of conversations. And some of them have to happen before others. And many of them happen more than once. So, to make it accurate, we’d probably have to add another dozen C s to the 3 C s. But happily, if you’re really having conversations and building shared understanding along the way, you’ll avoid lots of misunderstandings and course corrections.
每个故事都有与不同人进行的许多不同类型的对话。
There are many different kinds of conversations with different people for every story.
当你说出那个标题中的词时,我希望你会想起老电影《大白鲨》,在第一次近距离亲眼看到这条巨大的鲨鱼后,警察局长布罗迪对昆特说:“你需要一艘更大的船。”
When you say the words in that heading, I hope you’re thinking of the old movie Jaws when, after seeing the huge shark up close and personal for the first time, Police Chief Brody says to Quint, “You’re gonna need a bigger boat.”
你看,最初的想法也是,我可以拿起一张卡片,在正面写上标题,然后当我们交谈时,我可以把它翻到背面,写下我们同意的所有事情的细节上来了。我可以画出用户界面的草图,并在卡片上写下很多其他信息。在某些项目上,它确实可以这样工作。可以的话很酷,这通常是小团队紧密合作并拥有大量隐性知识的副作用。这些是不需要写太多就可以记住的团队。
You see, the original idea was also that I could pick up a card and write the title on the front, and then as we had conversations, I could flip it over on the back and write the details of all the things we agreed to that came up. I could sketch the user interface and write a lot of other information on the card. On some projects, it can really work this way. It’s cool when it can, and it’s usually a side effect of small teams working closely together with a lot of tacit knowledge. Those are the teams that don’t have to write much to remember.
但我认为即使是 Kent 和那些完善故事概念的人实际上也没有想到所有这些不同的人之间的所有这些对话都可以包含在一张卡片上,事实上,他们通常不会。
But I don’t think even Kent and the folks who perfected the concept of stories actually thought that all these conversations between all these different people could be contained on just a single card, and in fact, they usually aren’t.
对我有用的比喻是图书馆卡片目录中的一张卡片,对于年龄足够大的人来说,图书馆实际上有卡片目录。写在卡片上的故事有点像那些。
The metaphor that works for me is a card in a library card catalog, for people who are old enough to remember when libraries actually had card catalogs. Stories written on cards work a bit like those.
如果我从卡片目录中挑选一张卡片,它会提供足够的信息让我识别这本书。它可能有标题、作者姓名、描述、书的页数、书的类别(例如“非小说类”)和代码(还记得杜威先生的小数点吗?)到我可以实际找到的位置图书馆里的那本书的副本。该卡只是一个易于查找和整理的标记。没有人会将卡片与一本书混淆。卡片目录很方便,因为它比成千上万本书占用的空间要少得多。我可以用不同的方式组织卡片——例如,按作者或按主题。
If I pick up a card from a card catalog, it’s going to have just enough information for me to identify the book. It likely has a title, the author name, a description, the page count of the book, the category of the book—like “nonfiction”—and a code (remember Mr. Dewey’s decimals?) to a location where I can actually find a copy of the book in the library. The card’s just a token that’s easy to find and organize. No one confuses the cards with a book. The card catalog is handy because it takes a lot less space than thousands of books would. And I can organize cards in different ways—by author, for example, or by subject.
您的故事将以同样的方式运作;也就是说,您可以将它们写在卡片上,将它们保存在电子表格的列表中,将它们输入到您最喜欢的跟踪工具中,或者将它们输入到您公司让您使用的跟踪工具中——您知道,每个人都在抱怨这个工具。在图书馆里,您知道某处有一本书,如果您在卡片目录中找到了正确的卡片,就很容易找到它。同样,对于一个故事,您知道某处的信息量越来越多。它随着每次对话而成长和发展。而且,希望无论您的公司选择如何跟踪这些信息,它也很容易找到。
Your stories will work the same way; that is, you may write them on cards, keep them in a list in a spreadsheet, enter them into your favorite tracking tool, or enter them in the tracking tool your company makes you use—you know, the one everyone grumbles about. In a library, you know there’s a book out there somewhere, and if you have identified the right card filed away in the card catalog, it’s easy to find it. Similarly, with a story, you know there’s a growing amount of information out there somewhere. It grows and evolves with each conversation. And, hopefully, however your company chooses to keep track of the information, it’s easy to find, too.
如果你想去真正的老派,请保留细节所有这些讨论都贴在墙上的大张挂图纸上,这样你就可以随时谈论它们。但请记住:当你完成工作时,你会想把它们拿下来,否则你会用完墙上的空间。你会想要给它们拍照,并将这些照片保存在某个地方以供子孙后代使用。
If you want to go really old school, keep the details of all those discussions taped onto big sheets of flipchart paper on the wall so you can keep talking about them whenever you want. But remember: you’ll want to take them down when you’ve completed the work or else you’ll run out of wall space. And you’ll want to photograph them and keep those photos somewhere for posterity.
在他的《敏捷软件开发:合作博弈》(Addison-Wesley Professional)一书中,Alistair Cockburn 创造了术语信息辐射器来描述墙上有多大的可见信息将有用的东西辐射到房间里。路过的人看着它并与之互动。当信息活跃且有用时,许多对话最终会出现在墙上,人们可以指向并添加到那里积累的信息中。
In his book Agile Software Development: The Cooperative Game (Addison-Wesley Professional), Alistair Cockburn coined the term information radiator to describe how big, visible information on the wall radiates useful stuff into the room. People walking by look at it and engage with it. When the information is alive and useful, lots of conversations end up at the wall, where people can point to and add to the information accumulating there.
当我走进墙壁干净,甚至覆盖着令人愉悦的艺术品——或者最糟糕的是,励志海报——的环境时,我会感到难过。这些有用的墙壁每天都可能发生如此多的伟大合作。如果墙上的东西是一个信息辐射器,有些人将人们使用的工具称为信息冰箱——因为这是保存信息的地方——并且可能会被一层薄薄的冰覆盖,就像你的后背的东西一样冰箱。(我总是对我在那里的发现感到震惊。)
When I walk into environments where the walls are clear, or even covered with pleasant artwork—or worst of all, motivational posters—it makes me sad. There’s so much great collaboration that could be happening every day with those useful walls. If what’s on the wall is an information radiator, some refer to the tools people use as an information icebox—because that’s where information goes to be preserved—and potentially be crusted over with that thin layer of ice like that stuff in the back of your freezer. (I’m always shocked by what I find back there.)
这就是 Atlassian 对我来说真正了不起的地方。他们使信息保持活力和有用,无论是在他们使用的工具中还是在他们使用的工具之外。
That’s what’s really remarkable to me about Atlassian. They keep information alive and useful, both in and out of the tools they use.
伐木工人在森林里遇到了一个人。这个人正在努力工作,试图通过用锤子敲打来砍倒一棵树。伐木工人拦住男人说:“嘿,你用错工具了!试试这个……”然后递给那个人一把锯。男人向他道谢,伐木工人继续赶路,他很高兴知道自己帮了忙。然后这个人开始用锯子敲树,就像他用锤子一样。
A lumberjack comes across a man in the forest. The man is working hard trying to chop down a tree by hitting it with a hammer. The lumberjack stops the man and says, “Hey, you’re using the wrong tool! Try this…” and hands the man a saw. The man thanks him, and the lumberjack continues on his way, happily knowing that he’s helped. The man then begins striking the tree with the saw the same way he was with the hammer.
这个笑话提醒我,我们可以用错工具,也可以用错工具。
This joke reminds me that we can use the wrong tool for the job, and we can also use the tool wrong.
当我告诉人们像 Atlassian 这样的公司如何使用工具时,他们通常会感到惊讶。他们常常感到惊讶,因为他们一直在尝试使用工具来替代白板和便利贴。而且,可以预见的是,他们一直在努力解决这个问题。可能是他们为错误的工作使用了错误的工具,或者错误地使用了正确的工具。要弄清楚可能出了什么问题,最好先查看作业,而不是工具。
When I tell people how companies like Atlassian use tools, they’re usually surprised. They’re often surprised because they’ve been trying to use tools as a replacement for whiteboards and sticky notes. And, predictably, they’ve been struggling with that. It may be that they’re using the wrong tool for the wrong job, or using the right tool wrong. To figure out what might be going wrong, it’s best to look at the job first, and not the tool.
当我们共同讲述故事并就要构建的解决方案做出决策时,我们的首要目标是建立共同的理解。这就是外化和组织您的想法至关重要的地方。没有什么比在白板前用便利贴进行面对面的工作更好的了。但是,如果您必须与远程工作的其他人一起完成这项任务,那就很难了。让您看到彼此面孔的视频会议工具并没有太大帮助,因为您需要看到的不是他们的面孔,而是您将要放在墙上或桌面上的想法。
When we’re working together to tell stories and make decisions about solutions to build, our first goal is to build shared understanding. This is where externalizing and organizing your thoughts is critical. And nothing beats face-to-face work in front of a whiteboard, armed with sticky notes. But, if you’ve got to accomplish this task with others working remotely, this is tough. Video conference tools that let you see one another’s faces don’t help much, since it’s not their faces you need to see—it’s the ideas you’ll be placing on the wall or tabletop.
在视频会议期间使用文件摄像机或网络摄像机,让远程人员可以看到墙上正在创建的内容。
Use a document camera or web camera during a video conference to let remote people see what’s being created on the wall.
我曾与在视频会议两端都有摄像机的团队合作过,通话的重点是墙上不断增长的模型,而不是团队成员的脸。
I’ve worked with teams that have video cameras at both ends of a video conference, and the call focuses on the growing models on the wall, not the team members’ faces.
如果你使用一种工具来可视化,那么理想的情况是对话双方的人都可以添加和移动东西,就像他们在白板上一起工作一样。这是来自名为 Cardboard 的工具的屏幕。
If you use a tool to visualize, it’s ideal if people on both sides of the conversation can add and move things around, just like they could if they were working together at a whiteboard. This is a screen from a tool called Cardboard.
使用 Cardboard 的人正在创建地图,而 Cardboard 的创建者之一 David Hussman 在墙上绘制地图。从其他位置共享同一张地图的其他人会看到它实时汇集在一起。他们可以添加、删除和更改卡片,每个人都可以看到其他人在做什么。您几乎可以“退后一步”并立即查看整面墙,这很方便,因为计算机屏幕只是您在墙上工作时可以看到的内容的一个小入口。
The person using Cardboard is creating a map at the same time as David Hussman, one of Cardboard’s creators, maps on a wall. Others who are sharing the same map from other locations see it come together in real time. They can add, remove, and change cards, and everyone can see what everyone else is doing. You can virtually “step back” and look at the entire wall at once, which is handy because computer screens are just a tiny portal on what you could see if you were working at a wall.
远程协作时,使用允许每个人同时查看、添加和组织模型的工具。
When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently.
令人高兴的是,我看到越来越多的工具进入市场,它们理解并支持一起工作以建立共同的理解。这是一件好事。
Happily, I’m seeing a lot more tools enter the market that understand and support working together to build shared understanding. This is a good thing.
当我们一起努力达成一致时,我们应该保留我们创建的任何模型或示例的副本以用作度假照片——以帮助我们记住我们讨论过的所有细节。像 Atlassian 的 Confluence 这样的工具提供了丰富的 wiki,不仅可以存储文字,还可以存储图片和视频。一起工作后拍摄并保存照片和视频是最快的记录方式之一。
When we’ve worked hard together to get on the same page, we should be keeping copies of whatever models or examples we’ve created to use as vacation photos—to help us remember all the details we’ve discussed. Tools like Atlassian’s Confluence offer a rich wiki for storing not just words, but also pictures and video. Taking and keeping pictures and videos after working together is one of fastest ways to document.
Atlassian 的这些人正在这样做。他们在墙上工作后拍了一张照片,并将其上传到他们的 wiki 以妥善保管。
These folks at Atlassian are doing just that. They’ve snapped a picture after working at a wall, and uploaded it to their wiki for safekeeping.
使用工具发布图片、视频和文本,以帮助您保留和记住您的对话。
Use tools to post pictures, videos, and text to help you retain and remember your conversations.
我个人喜欢保持低保真并在墙上保留信息,但如果我担心清洁工在晚上将其取下,我会拍照并保存以防万一。如果我要与不能在房间里的人分享信息,即使是虚拟的,我也会拍摄一段短视频,介绍墙上的模型,并将其张贴在其他人可以看到的地方。
I personally like staying lo-fi and keeping information on the wall, but if I worry at all about a cleaning person taking it down at night, I’ll photograph and keep it just in case. If I’m sharing information with people who couldn’t be in the room, even virtually, I’ll shoot a short video stepping through the model on the wall and post that where others can see it.
工具最擅长的事情之一就是完成我们计划要做的所有工作,并让我们跟踪其进度。工具可以很好地跟踪对我们来说很乏味的数字——比如我们确切的开始时间、完成时间以及还有多少事情要做。当我们定期跟踪我们正在做的事情时,更好的工具将为我们产生有用的见解。
One of the things that tools most excel at is taking all the work we’ve planned on doing, and letting us track its progress. Tools are great at keeping track of the numbers that are tedious for us—things like exactly when we started, when we finished, and how much we’ve got left to do. The better tools will generate useful insights for us as we routinely track what we’re doing.
这是Atlassian的JIRA产品生成的累积流程图。这是一张图表,显示我们正在做的工作及其随时间的状态。这是一张我不愿意手工制作的图表。
This is a cumulative flow diagram generated by Atlassian’s JIRA product. It’s a chart that shows the work we’re doing and its state over time. And it’s a chart I would hate to produce by hand.
对于单一的、并置的团队和小型项目,墙就可以了。但是,如果您有更大的团队在不同的物理位置工作,并且项目运行时间更长,请使用工具来跟踪所有细节。
For single, collocated teams and small projects, the wall will do just fine. But, if you’ve got larger teams working from different physical locations, and longer-running projects, use a tool to keep track of all the details.
使用工具来排序、跟踪和分析进度。
Use tools to sequence, track, and analyze progress.
诀窍是为正确的工作使用正确的工具。不要尝试使用非常棒的跟踪工具来建立共同的理解。不要费力地在白板上进行复杂的分析。
The trick is using the right tool for the right job. Don’t try to use a really great tracking tool to build shared understanding. And don’t struggle to do complex analysis on a whiteboard.
保持事情简单快速,尽可能多地在索引卡和白板上工作一直是敏捷的理想。我向你保证,如果你能保持小而快,避免使用不必要的工具,你会更快乐。但请记住:这些工具只是达到目的的一种手段。接下来,我们需要谈谈卡片之后会发生什么。
It’s been an Agile ideal to keep things simple and fast, to stay working on index cards and whiteboards as much as possible. And I promise you if you can stay small and fast and avoid unnecessary tools, you’ll be happier. But remember: those tools are just a means to an end. Next, we’ll need to talk about what happens after the card.
三个C只是开始。
The three C s are just the beginning.
我知道我之前说过我没有义务引用敏捷宣言,但无论如何我都会引用——好吧,至少引用其中的一小部分。宣言中的价值陈述之一是“工作软件胜过综合文档”。我可以将其改写为“综合对话中的工作软件”,意思是一样的。所有这些对话——以及帮助我们回忆它们的文档——只是达到目的的一种手段。最终我们需要建造一些东西。
I know I said earlier that I don’t feel obligated to quote the Agile Manifesto, but I’m going to anyway—well, at least a small part of it. One of the value statements in the manifesto reads “Working software over comprehensive documentation.” I could rephrase that as “working software over comprehensive conversation,” and the meaning would be the same. All those conversations—and the documentation that helps us recall them—are just a means to an end. Eventually we’ll need to build something.
如果我们完成循环,模型如下所示:
If we finish the cycle, the model looks like this:
在我们对我们将要构建的内容达成共识并达成共识之后,总会有一些问题潜入这里。留意他们。
There are some gotchas that always manage to sneak in here after we’ve got shared understanding and agreement on what we’ll build. Keep an eye out for them.
在进行对话并写下有助于我们记住这些对话的细节并写下确认之后——也就是说,我们同意我们将检查以确认我们已经完成的事情——我们终于准备好做一些事情了:
After having conversations, and writing down details that’ll help us remember those conversations, and writing down confirmation—that is, our agreement about the things we’ll check to confirm we’re done—we’re finally ready to make something:
这里最重要的是,所有这些人的脑袋里都装着同一张图:他们 一起谈话时构建的图。
The most important thing here is that all these people are armed with the same picture in their heads: the picture they built while talking together.
我要在这里暂停一下。
I’m going to pause here for effect.
现在,我要慢慢说下一部分,所以你应该慢慢读。
Now, I’m going to say this next part slowly, so you should read it slowly.
将故事的所有细节交给其他人来构建是行不通的。不要那样做。
Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.
如果你和一群人一起工作来理解应该构建什么,并且如果你已经记录了构建它需要知道的所有重要事情,那么你可能很想把它交给其他人。毕竟,当您查看这些信息时,它对您来说一清二楚。但不要自欺欺人。你很清楚,因为你真正聪明的大脑正在填写所有没有写下来的细节。你的大脑非常擅长它,以至于你很难发现可能遗漏了什么。请记住,这些细节是您的度假照片,而不是他们的。
If you and a group of people have worked together to understand what should be built, and if you’ve documented all the important things someone needs to know to build it, you may be very tempted here to hand it off to someone else. After all, when you look at the information, it’s crystal clear to you. But don’t fool yourself. It’s clear to you because your really smart brain is filling in all the details that aren’t written down. Your brain is so good at it that it’s hard for you to detect what could be missing. Remember, those details are your vacation photos, not theirs.
分享故事相当简单。真正理解故事的人,以及收集到的有助于讲述故事的信息,只需要花一点时间将故事复述给下一个需要学习的人。现在,这应该比你们一起做出艰难决定的早期对话要快得多,因为希望你们不需要重新做出决定。使用所写的内容来帮助讲述故事。说话并指着图片。让您的听众提出问题并对图片进行修改以帮助她记住。帮助她将与故事相关的信息变成她自己的度假照片。
Sharing stories is reasonably simple. Someone who does understand the story, and the information collected that helps tell the story, needs only spend a little time retelling the story to the next person who needs to learn. Now, this should go lots faster than early conversations where you worked together to make tough decisions, since hopefully you won’t need to remake them. Use what’s written to help tell the story. Talk and point to pictures. Let your listener ask questions and make changes to the pictures that help her remember. Help her turn the information associated with the story into her own vacation photos.
我经常在这里看到一个讨厌的反模式。有些人认为,既然团队中的任何人都可能会拿起故事并为之工作,那么团队中的每个人都应该参与到每一次对话中。也许你在这家公司工作。你会知道的,因为你会听到很多人抱怨会议太多了。顺便说一句,“会议”通常是我们用来指代无效协作的委婉说法。
There’s a nasty anti-pattern I often see here. Some think that since anyone in a team might pick up the story and do work on it, everyone on the team should be involved in every conversation. Perhaps you work at this company. You’ll know it because you’ll hear lots of people complaining that there are way too many meetings. By the way, “meeting” is often the euphemism we use for unproductive collaboration.
两到五人的小组最适合进行有效的讨论和决策。这是晚餐谈话的大小。您知道,如果您有一群朋友共进晚餐,那么在只有几个人的情况下很容易进行一次对话。但只要超过五个人,它就会成为真正的努力。
Effective discussion and decision making goes best with small groups of two to five. It’s dinner conversation sized. You know that if you have a group of friends sharing a meal, it’s easy to hold a single conversation when there are just a few of you. But any more than about five people is where it becomes a real effort.
让小组一起做决定,然后通过持续的对话与其他人分享结果。
Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.
如果你在团队中,你们将一起工作,并对你正在构建的内容和原因有共同的理解。当你们一起工作时,你们会一直进行对话,因为你们永远不会考虑所有事情。但是当软件完成后,你们会一起回来讨论它。
If you’re on the team, you’ll all work together armed with shared understanding about what you’re building, and why. As you work together, you’ll keep having conversations because you never think of everything. But when the software is done, you’ll all come back together and talk about it.
现在是祝贺自己工作出色的好时机。看到真正的进步真是太棒了。在传统的软件开发中,看到辛勤工作成果的机会要少得多,而且很少作为团队共享。在像 Scrum 这样的典型敏捷流程中,您将每隔几周在冲刺结束时进行一次产品评审。在最健康的团队中,团队成员经常聚在一起检查他们完成的工作。但你需要超越展示和讲述。祝贺自己之后,花点时间对自己所做工作的质量进行简短而认真的反思。
This is a good time to congratulate yourselves on a job well done. It’s pretty cool to see real progress. In traditional software development, the opportunities to see the results of your hard work can come a lot less frequently, and they’re rarely shared as a team. In a typical Agile process like Scrum, you’ll be sharing every couple of weeks at an end-of-sprint product review. In the healthiest of teams, team members get together frequently to inspect their work as it’s done. But you’ll need to go beyond show and tell. After congratulating yourselves, take time for a short but serious reflection on the quality of the work you did.
说到质量,我先从这三个方面开始讨论:
When talking about quality, I start with discussions of these three aspects:
我有一些坏消息要告诉你。你可能会发现你认为应该改变你所做的事情。
I have some bad news for you here. You’re likely to find things you believe should change about what you’ve done.
将两个问题分开会有助于每个人的理智。第一:我们是否建造了我们同意建造的东西?然后:如果这是我们同意建造的,既然我们看到了,我们是否应该做出一些改变?
It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?
每个人都会在一开始就一起努力工作,以弄清楚要构建什么来解决用户的问题并且构建起来是经济的。您将尽最大努力确定要检查的内容以确认它已完成。检查所有这些事情,如果你已经完成那么多,祝贺你自己。你得到的正是你同意你想要得到的。
Everyone will have worked hard together at the outset to figure out what to build that would solve users’ problems and be economical to build. You’ll have done your best to identify the things to check to confirm that it’s done. Check all those things, and congratulate yourselves if you’ve accomplished that much. You got exactly what you agreed you wanted to get.
现在,我脑海中浮现出一些滚石乐队的老歌歌词。如果你知道这首歌,请跟着哼唱:“你不能总是得到你想要的。但是,如果你尝试一下,你可能会发现,你得到了你需要的东西。” 具有讽刺意味的是,软件恰恰相反。
Now, here’s where some old Rolling Stones song lyrics play in my head. If you know the song, hum along: “You can’t always get what you want. But, if you try sometime, you just might find, you get what you need.” The irony with software is that it’s exactly the opposite.
你们将共同努力,就你们想要的达成一致。而且,如果您与一个有能力的团队一起工作,您会发现您可以非常擅长获得它。但是,只有在看到它之后,您才能更好地评估它是否是您需要的。这很糟糕。但不要责怪自己——事情就是这样。
You’ll work together to agree on what you want. And, if you’re working with a competent team, you’ll see that you can get pretty good at getting it. It’s only after seeing it, though, that you can better evaluate if it’s what you need. This sucks. But don’t blame yourselves—that’s just the way it works.
但是,您确实有办法修复它。它首先写一张卡片,上面写着你对软件进行哪些更改以修复它的想法。当然,如果您一开始就打算做对,这就很糟糕了。也许 Mick Jagger 终究是对的。也许你真正需要的是了解第一次就正确是一种冒险的策略——尤其是在软件领域。
You do, however, have a way of fixing it. And it starts by writing a card with your ideas about what to change in the software to fix it. This, of course, sucks if you’d planned on being right the first time. Maybe Mick Jagger was right after all. Maybe what you really needed was to learn that being right the first time is a risky strategy—especially in software.
对不起。我有更多的坏消息。
I’m sorry. I’ve got even more bad news.
实际上,最初编写卡片并开始整个循环的人很可能不是每天都会使用该软件的人。最初编写这张卡片的人,以及一起工作的整个团队,可能相信他们已经做到了——他们已经为目标用户所面临的挑战构建了完美的解决方案。
In reality, the person who originally wrote the card and who started this entire cycle is likely not the person who will use the software every day. The person who originally wrote the card, and the entire team who worked together, may believe they’ve nailed it—that they’ve built the perfect solution to the challenges their target users have.
不要自欺欺人。
Don’t fool yourself.
如果我们一起加入这个团队并且我们很聪明,我们会将软件带给用户并与他们一起测试。这也不是展示和讲述。我们将通过观察他们使用该软件来实现他们通常需要使用该软件来实现的真实目标来进行测试。
If we’re on this team together and we’re smart, we’ll take the software out to users and test it with them. This isn’t show and tell, either. We’ll test by watching them use the software to reach a real goal they’ll normally need to accomplish using the software.
当某人使用您帮助构建的软件时,您是否曾与她坐在一起?回想一下你第一次这样做。进展如何?当时我不在房间里和你在一起,但我敢打赌,事情并没有像你预期的那样进行。
Have you ever sat with someone as she uses software you’ve helped build? Think back to the first time you did. How did it go? I wasn’t in the room with you at the time, but I’m willing to bet that it didn’t go the way you expected.
如果您曾经在用户使用您的产品时坐在她旁边,您就会明白我的意思。如果您从未这样做过,那就去做吧。
If you’ve ever sat next to a user as she uses your product, you know what I mean. If you’ve never done this, then do it.
您需要对实际购买、采用和使用您的产品的人进行测试,这些人会以一定的频率定期使用您的产品。我经常等到我构建了一些软件——足够他们可以用它来完成他们以前无法完成的事情。无论您采用何种频率,都不要让超过几周的时间没有看到真正的用户与该软件进行交互。
You’ll need to test with the people who’ll actually buy, adopt, and use your product at some regular frequency. I often wait until I’ve built up a bit of software—enough that they could use it to accomplish something they couldn’t before. Whatever frequency you adopt, don’t let more than a couple weeks go by without seeing a genuine user interact with the software.
团队中的每个人都不需要与用户在一起。事实上,如果每个人都这样做,它会让用户感到厌烦。但是在那里建立同理心,你不会得到任何其他方式。看到人们努力使用您的产品是一种强大的动力,尤其是当您确信他们不需要时。如果您在场,请通过向他人讲述故事来与他人分享您的所见所闻。
Everyone on the team doesn’t need to be there with users. In fact, it’ll kind of creep the users out if everyone is. But being there builds empathy that you won’t get any other way. It’s a powerful motivator to see people struggling to use your product, especially when you were so confident they wouldn’t need to. If you were there, share what you saw with others by telling stories back to them.
与用户一起测试后,您将确定要解决的问题和改进软件的明显方法。对于其中的每一件事,您都应该写一张故事卡,其中包含您改进软件的想法。
After testing with users, you’ll identify problems to fix and obvious ways to improve the software. And for each one of those things, you should write a story card with your ideas for improving the software.
如果您一直相信使用故事可以阻止您的团队编写糟糕的软件,那么您至少对了一半。事实上,聪明人之间的所有对话都集中在理解问题上——以及我们正在构建的产品如何解决它——对制造更好的产品大有帮助。但我们需要承认,构建软件与在流水线上工作不同。您不只是像几分钟前构建的那样再构建一个小部件。我们创建软件支持的每个新故事都是新事物。
If you’d labored under the belief that using stories would stop your team from writing bad software, you were at least half right. In fact, all the conversations between smart people focused on understanding the problem—and how what we’re building solves it—go a long way toward making a much better product. But we need to acknowledge that building software isn’t the same as working on an assembly line. You’re not just building one more widget like the one you built a few minutes ago. Each new story we create software to support is something new.
敏捷开发社区中的一位杰出人物是我的前面提到的朋友,Alistair Cockburn,他曾经告诉我,“对于你写的每一个故事,你需要将三个故事放入积压的故事中。”
One of the luminaries in the Agile development community is my aforementioned friend, Alistair Cockburn, who once told me, “For every story you write, you need to put three into your backlog of stories.”
我问他为什么,他说:“你就是这样。”
I asked him why, and he said, “You just do.”
我问:“另外两个应该写什么?”
I asked, “What should I write on the other two?”
“你写什么并不重要。”
“It doesn’t matter what you write.”
“你是什么意思?” 我问:“我必须在上面写点东西! ”
“What do you mean?” I asked, “I have to write something on them!”
阿利斯泰尔回答说:“好吧,如果你必须在上面写点什么,那就在第一张卡片上写下你想要的东西,然后在第二张卡片上写下‘修复第一张卡片’。” 然后在第三张卡片上,写下“修复第二张卡片”。如果你不为每个故事绕过这个循环 3 次,你就不是在学习。”
Alistair replied, “Well, if you have to write something on them, then write what you want on the first card, and on the second card write ‘Fix the first card.’ Then on the third card, write ‘Fix the second one.’ If you aren’t going around this cycle three times for each story, you’re not learning.”
在传统流程中,学习被称为范围蔓延或不良需求。在敏捷过程中,学习是目的。您需要计划从您构建的所有内容中学习。而且你需要计划在相当多的时间里犯错。
In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose. You’ll need to plan on learning from everything you build. And you’ll need to plan on being wrong a fair bit of the time.
Eric 在第 3 章中使用的策略帮助他构建较小的解决方案并继续迭代它们直到它们可行。Eric 指望从每个版本中学习。
Eric’s strategy used in Chapter 3 helped him build smaller solutions and continue to iterate them until they were viable. Eric counted on learning from every release.
蒙娜丽莎策略_Mike 和 Aaron 在第 4 章中使用的方法帮助他们将每个故事分成更小、更薄、无法交付的部分,这样他们就可以更快地学习并明智地管理他们的交付预算以按时完成。
The Mona Lisa strategy used by Mike and Aaron in Chapter 4 helped them slice every story down into smaller, thinner, undeliverable bits so they could learn sooner and manage their delivery budget wisely to finish on time.
这些都是很好的学习策略。试试那些。发明你自己的。但请不要假设你总是对的。我保证你会失望的。
These are both great learning strategies. Try those. Invent your own. But please don’t assume you’re always right. I promise you’ll be disappointed.
2011 年,故事的作者肯特·贝克 (Kent Beck) 通过对敏捷宣言的修订开启了首批精益创业会议之一。如果我这样做了,那可能就是亵渎神明。但他是它的创造者之一,所以他应该知道。他修改了阅读有关工作软件的价值:
In 2011, Kent Beck—the creator of the story—opened one of the first Lean Startup conferences with his revision of the Agile Manifesto. If I’d done it, it might have been blasphemy. But he’s one of its creators, so he should know. He revised the value about working software to read:
通过工作软件(或综合文档)验证学习
Validated learning over working software (or comprehensive documentation)
如果您还记得第 3 章,经过验证的学习是来自精益创业过程的超级有价值的概念。那里的关键词是学习。使它成为有效学习的原因是讨论我们想要学习什么作为制作某物的一部分,然后回过头来考虑后果——反思我们学到了什么或没有学到什么。我们意识到的一件事是,我们并不总是需要构建软件来学习。但我们通常确实需要制作或做某事。
If you remember from Chapter 3, validated learning is the super-valuable concept that comes from the Lean Startup process. The key word there is learning. What makes it validated learning is discussing what we want to learn as part of making something, and then going back and considering the consequences—reflecting on what we learned or didn’t learn. And one of the things we’re realizing is that we don’t always need to build software to learn. But we do usually need to make or do something.
我喜欢用故事来推动我们所做的工作,以构建简单的原型,或者计划我们正在做的采访或观察用户的工作。我也喜欢谈论这些事情的人物、内容和原因。我喜欢在我们制作之前就我们将制作的东西达成一致。我回顾了这样做的后果,以考虑我们学到了什么。
I like using stories to drive the work we do to build simple prototypes, or to plan the work we’re doing to interview or observe users. I like talking about the who, what, and why for those things, too. I like agreeing on what we’ll make before we make it. And I look back at the consequences of having done it to consider what we’ve learned.
尝试使用故事来推动任何东西的制作,无论它是不是软件。
Try using stories to drive the making of anything, whether it’s software or not.
故事地图对于将我们的大产品或功能创意分解成更小的部分很有用。第 3章和第 4 章是关于将这些较小的部分分割成可构建的块,其中每个块都专注于学习一些东西。但是有一种不同的方法可以分解你需要注意的事情,并在你的头脑中保持独立。这是我们将故事分解成我们制作某物的计划的工作。这就是我们将在下一章中讨论的内容。
Story maps are useful for breaking up our big product or feature ideas into smaller parts. Chapter 3 and Chapter 4 were about slicing up those smaller parts into buildable chunks where each chunk was focused on learning something. But there’s a different way to break things down that you need to be aware of, and to keep separate in your head. It’s the work we do to break down a story into our plan to make something. That’s what we’ll talk about in the next chapter.
两周前是我女儿的生日,我们想要一个蛋糕。我们家有自己的面包师——我们请他来做蛋糕。现在,我们不富裕也不害怕自己做蛋糕。只是我们的面包师 Sydnie 制作的蛋糕非常美味。我们不知道她究竟施展了怎样的烹饪魔法来实现这一目标,但每当我们问孩子们想要什么样的生日蛋糕时,他们都会大喊“我们想要一个悉尼蛋糕!” 为我们的面包师敲定交易。
Two weeks ago it was my daughter’s birthday and we wanted a cake. Our family has our own baker—a person we call to make our cakes. Now, we’re not rich or afraid to make cakes ourselves. It’s just that Sydnie, our baker, makes incredibly fantastic-tasting cakes. We don’t know exactly what culinary magic she wields to pull it off, but whenever we ask our kids what kind of cake they want for their birthday, the shout “We want a Sydnie cake!” seals the deal for our baker.
为了买蛋糕,我打电话给 Sydnie。她会问蛋糕是给谁的,是什么场合。两周前我告诉她格蕾丝快 12 岁了。“格蕾丝喜欢什么?” 她问。我们聊了聊 Grace 喜欢什么以及她在想什么。我们也聊了聊Sydnie有什么形状的蛋糕盘,她能及时准备好什么样的蛋糕设计是可行的。这次我们同意做一个鸟形蛋糕。
To get a cake, I call Sydnie on the phone. She’ll ask who the cake is for and what the occasion is. Two weeks ago I told her Grace was turning 12. “What’s Grace into?” she asks. We talk a bit about what Grace likes and what she was thinking of. We also talk about what shapes of cake pans Sydnie has, and what kind of cake design is feasible for her to have ready in time. We agree on a bird-shaped cake this time.
这就是讲故事的方式。Sydnie 问了很多关于谁、什么和为什么的问题。她询问了背景——我们将在何时何地提供蛋糕,以及那里会有多少人。在谈话中,我们考虑了几个不同的选择。我们谈了足够长的时间来建立共同的理解。而且,因为我们从 Sydnie 那里得到了很多蛋糕,所以我们已经对它们的外观和味道有了一些共同的了解。如果我们不这样做,我们会想看一些照片或品尝一些蛋糕,而手机就不能很好地满足这些需求。
That’s how telling a story works. Sydnie asked lots of who, what, and why questions. She asked about the context—where and when we’d be serving the cake, and how many people would be there. During the conversations, we considered a few different options. We talked long enough to build shared understanding. And, because we’ve gotten lots of cakes from Sydnie, we already have some shared understanding about how they’ll look and taste when we get them. If we didn’t, we’d have wanted to see some pictures or taste some cake, and the phone wouldn’t have worked well for that.
在我们的讨论中,Sydnie 正在考虑如何制作蛋糕。她必须这样做,这样她才能弄清楚她是否能及时赶到。到了做蛋糕的时候,她会列出一份她需要做的事情的清单——比如测量面粉、糖、黄油、鸡蛋和牛奶。她需要混合、烘烤、装饰,并可能执行其他一些我不知道的绝密步骤。我怀疑她对不同种类的蛋糕有不同的食谱,还有一张清单,列出了每个蛋糕在装进盒子准备拿走之前必须做的事情。如果 Sydnie 写下她必须做的所有事情的清单,她就会有一个充满特定蛋糕烘焙任务的工作计划。
During our discussion, Sydnie is thinking about how she’ll make the cake. She has to so she can figure out if she can make it in time. When it comes time to make the cake, she’ll have a list of things she’ll need to do—things like measuring flour, sugar, butter, eggs, and milk. She’ll need to mix, bake, decorate, and likely perform some other top-secret steps I don’t know about. I suspect she has different recipes for different kinds of cakes, and a checklist of things she has to do for every cake before it’s stuck in a box and ready to pick up. If Sydnie wrote down the list of all the things she has to do, she’d have a work plan full of specific cake-baking tasks.
当有人将故事带给开发团队时,也会发生同样的事情。他们一起决定具体要构建什么,开发团队制定他们的工作计划,由许多开发任务组成。开发团队包括测试人员、UI 设计人员、技术编写人员或创建软件所需的任何人员和技能,因此任务不仅仅与编码有关。而且,就像 Sydnie 在电话中与我交谈时没有制定她的计划一样,开发团队也不太可能在故事对话期间制定他们的计划。但他们会倾听、做笔记、画图并收集制定计划所需的大量细节。至少,这是我们希望的方式。
The same thing happens when someone brings a story to a development team. Together they make decisions on specifically what to build, and the development team creates their work plan, composed of lots of development tasks. The development team includes testers, UI designers, technical writers, or whatever people and skills are necessary to create the software, so the tasks aren’t all about coding. And, just like Sydnie didn’t create her plan while she talked with me on the phone, the development team won’t likely create their plan during the story conversation. But they will listen, take notes, draw pictures, and gather lots of the details they’ll need to create their plan. At least, that’s the way we hope it goes.
与 Sydnie 交谈时,我不会讲关于糖和面粉的故事。除非我的目标是建造一个烤箱,否则我不会讲关于烘焙的故事。当您讲述有关软件的故事并收集故事名称列表时,您在讲述故事时会想象您最终将拥有的软件。您不仅要想象软件,还要思考和谈论谁在使用它以及为什么使用它。Sydnie 并没有拘泥于蛋糕的细节,她问我蛋糕是给谁吃的,我女儿喜欢什么,聚会会有多少人,还有很多信息帮助我们一起决定最好的蛋糕应该是什么。Sydnie 不只是询问蛋糕要求,我们还共同努力决定制作我们都喜欢的蛋糕的最佳方式。这就是故事对话背后的真正精神。
When talking with Sydnie, I don’t tell stories about cups of sugar and flour. I wouldn’t tell a story about baking unless my goal was to build an oven. When you tell stories about software, and collect a list of story names as you do, you tell the story imagining the software you’ll have in the end. And you don’t just imagine the software—you think and talk about who uses it and why. Sydnie didn’t just stick to details about the cake, she asked me who it was for, what my daughter liked, how many people would be at the party, and lots of information that helped us decide together what the best cake should be. Sydnie wasn’t just asking for cake requirements, we were working together to decide on the best way to create a cake we’d all love. That’s the real spirit behind a story conversation.
但只有一件事。这里经常出现的问题是,当我们开始向真正有能力将我们的愿景变为现实的人讲述这个故事时,我们很快就会发现我们的故事所描述的软件非常庞大。好吧,上面写着它的卡片和其他卡片一样大。我们的用户试图通过它达到的目标对他们来说可能并不比其他人更重要,但是当我们谈论它时,我们意识到编写实现该目标所需的软件需要花费大量时间。
But there’s just one thing. Often what goes wrong here is that, when we start telling the story to people who are really capable of turning our vision into reality, we quickly figure out that the software our story describes is really big. Well, the card it’s written on is the same size as all the others. And the goal our users are trying to reach with it may be no more important to them than others, but it’s when we talk about it that we realize it’ll take a lot of time to write the software necessary to reach that goal.
当我和 Sydnie 谈论我的蛋糕时,同样的事情也可能发生。我本可以想象一个精致的蛋糕需要 Sydnie 没有的蛋糕盘,或者她没有掌握的蛋糕制作和装饰技术。结果将是一个我买不起的蛋糕,而且 Sydnie 也无法在我女儿生日前送出。
The same thing could have happened when I was talking with Sydnie about my cake. I could have imagined an elaborate cake that calls for cake pans Sydnie doesn’t have, or cake-building and decorating techniques she’s not mastered. The result would be a cake I can’t afford, and one that Sydnie couldn’t predictably deliver before my daughter’s birthday.
在第 7 章中,我指出,当我们考虑的解决方案过于昂贵时,我们需要退后一步,真正审视我们正在努力解决的问题,以及我们正在努力实现的结果。我们需要考虑其他选择。这是获得较小蛋糕或馅饼的一种方法?
In Chapter 7, I pointed out that when the solution we’re thinking of is too expensive, we need to step back and really look at the problems we’re trying to solve, and the outcomes we’re trying to achieve. And we’ll need to consider other alternatives. That’s one way to get a smaller cake—or maybe a pie?
如果故事描述的解决方案成本太高,请考虑另一种可以帮助您实现目标的解决方案。
If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal.
但是,如果它真的很大,而且我们负担得起,那么就没有理由把它分解得更小,对吧?好吧,实际上是有的。对于软件,尤其是通过将事物分成更小的部分来构建,我们可以更快地看到和衡量进展。这有助于花钱的人不那么紧张。而且,就像第 4 章的蒙娜丽莎策略一样,它可以帮助制造产品的人评估零件,以确保我们走在正确的轨道上。
But, if it’s really big, and we can afford it, then there’s no reason to break it down any smaller, right? Well, actually, there is. With software, especially, by building things in smaller parts, we can see and measure progress sooner. This helps the people spending money feel a bit less nervous. And, as in Chapter 4’s Mona Lisa strategy, it helps the people making the product evaluate parts to make sure we’re on the right track.
如果故事描述了一个经济实惠但规模庞大的解决方案,请将其分解成更小的部分,以便您能够更快地进行评估和看到进展。
If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
有一个分解大故事的技巧,它可以帮助我在脑海中记住蛋糕的比喻。如果你喜欢蛋糕,现在你可能会饿了——尤其是当你想象中的蛋糕特别好吃的时候。对于那个很抱歉。
There’s a trick to breaking down large stories, and it helps me to keep the cake metaphor in my head. If you like cake, by now you might be getting hungry—especially if the cake you’re imagining is a particularly tasty one. Sorry about that.
假设我们的故事描述了对更大蛋糕的需求,例如可以供数百人食用的超大婚礼蛋糕。如果是这样,那么它不再只是几杯面粉和糖,而是麻袋面粉和糖。大多数人以同样的方式分解软件。不仅仅是一点用户界面、一点业务逻辑和一点数据库交互,每个都有很多。但请记住,软件不是蛋糕。量两磅面粉所花的时间并不比量两杯面粉所花的时间多。但是为 20 个屏幕构建用户界面比仅仅为 2 个屏幕构建用户界面要花费更多的时间。因此,如果团队使用看似合乎逻辑的简单分解结构,他们很容易将软件分解为数周的前端开发、数周的业务逻辑开发等。当我们使用该策略时,我们需要很长时间才能“尝到任何蛋糕”,可以这么说。所以不要那样做。
Let’s say our story describes a need for a lot bigger cake, like a super-giant wedding cake that will feed hundreds of people. If so, then it isn’t just cups of flour and sugar anymore, it’s sacks of flour and sugar. Most people break down software the same way. Instead of just a little user interface, a little business logic, and a little database interaction, there’s lots of each. But remember that software isn’t cake. It doesn’t take that much more time to measure two pounds of flour than it does to measure two cups of flour. But building the user interface for 20 screens takes a lot more time than for just 2 screens. So, if teams use the simple breakdown structure that seems logical, they get tempted to break software down into weeks of frontend development, weeks of business logic development, and so on. When we use that strategy, it takes a long time before we can “taste any cake,” so to speak. So don’t do that.
不要把大事分解成大计划。用小计划将大事化为小事。
Don’t break down big things into big plans. Break big things into small things with small plans.
现在这个比喻真的要在这里崩溃了,但再坚持一分钟。处理一个大软件蛋糕的方法是将它分解成许多小蛋糕。每一个都是可交付的,每一个都有相似的食谱,加一点糖,一点面粉,一两个鸡蛋,等等。
Now the metaphor is really going to break down here, but stick with me for just one more minute. The way you approach a big software cake is to break it down into lots of little cupcakes. Each one is deliverable, and each one still has a similar recipe, with a little sugar, a little flour, an egg or two, and so on.
好的,现在让我们再认真一点。软件不是蛋糕。它可能变得巨大、极其昂贵且风险极大。在我撰写本文时,我刚刚在早间电视新闻中听到另一个故事,即美国政府未能通过网站为人们注册医疗保健。事后批评很容易。但也很容易看出,在比喻婚礼上送蛋糕之前,没有人尝过蛋糕——至少没有人尝过。那个半生不熟的蛋糕毁了聚会。
OK, now let’s get a little more serious again. Software isn’t cake. It can get huge, horrendously expensive, and horribly risky. As I write this text, I’ve just heard yet another story on the morning television news of the US government’s failed website to sign people up for healthcare. It’s easy to criticize after the fact. But it’s also easy to see that no one tasted that cake before it was served at the metaphoric wedding—at least no one with any taste. And that half-baked cake ruined the party.
如果您在更传统的软件开发领域工作过一段时间,您可能学会了将大型软件分解为大型计划。我知道我做到了。将大的东西分解成看起来不太像您要交付的成品的小块似乎有悖常理。您会知道,在组合这些软件部分时,您必须对每个部分进行一些重写和调整才能将它们组合起来。但请记住——您有很多充分的理由这样想。最大的挑战之一是避免因太晚未看到、使用或“品尝”软件而带来的风险。你正在把大事分解成小的、可评估的部分,这样你就可以更快地学习。
If you’ve worked in more traditional software development for a while, you likely learned to break down big software into big plans. I know I did. It’ll seems counterintuitive to break down something big into smaller pieces that may not quite look like the finished product you’re trying to deliver. You’ll know that as you combine these pieces of software, you’ll have to do a bit of rewriting and adjusting of each piece to combine them. But remember—you’re thinking this way for lots of good reasons. One of the biggest is to avoid the risks involved with not seeing, using, or “tasting” the software too late. You’re breaking big things down to small, evaluable parts so you can learn sooner.
如果我分解蛋糕的目的是为了早点品尝它或早点看到装饰,我最好烤一些小纸杯蛋糕来帮助我更快地学习。我会烤一些不同口味的,这样我就可以品尝到所有的口味,选择我最喜欢的,并确信我做出了正确的选择。如果我关心颜色和装饰,我会想看看不同风格装饰的不同纸杯蛋糕,然后选择最好的那一款。
If I were breaking down a cake with the goal of tasting it sooner or seeing the decoration sooner, I’d do well to bake small cupcakes that help me learn sooner. I’d bake some in a number of different flavors so I could taste them all, choose the one I liked best, and be confident I’d made the right choice. If I were concerned about colors and decoration, I’d want to look at different cupcakes decorated in different styles, and choose the one that was best.
对于软件,纸杯蛋糕是工作软件的一部分,允许用户评估他们是否可以有效地完成用户任务。它们可能是帮助暴露技术风险的软件部分。但是每件作品都可以帮助我们学到一些东西。
With software, the cupcakes are portions of working software that allow users to evaluate if they can effectively complete a user task. They may be portions of software that help expose a technical risk. But each piece helps us learn something.
但是一堆纸杯蛋糕不是结婚蛋糕——是吗?[ 11 ]
But a pile of cupcakes isn’t a wedding cake—or is it?[11]
软件不是蛋糕。我们构建的每个软件都以一种蛋糕无法做到的方式组合成一个更大的工作产品。
Software isn’t cake. And every piece of software we build does combine into one larger working product in a way that cake can’t.
我的朋友 Luke Hohman 有一句愚蠢的口头禅是你可以送“半个烤蛋糕,而不是半生不熟的蛋糕”。半个烤好的蛋糕可能不足以满足一场婚礼的需要,但足以让每个人品尝并期待剩下的蛋糕。
One of the silly mantras that comes from my friend Luke Hohman is that you can deliver “half a baked cake, not a half-baked cake.” Half a baked cake may not be enough to feed a wedding party, but it’s enough to taste and leave everyone looking forward to the rest of the cake.
故事的最初想法非常简单——在卡片上写点东西,讨论它,然后就构建什么达成一致。然后,通过构建它并从您构建的内容中学习来完成循环。就是这样——非常简单,对吧?如果您参与软件开发的时间很短,您就会知道没有那么简单。故事经历了一段漫长的旅程,其中涉及很多人的大量对话,将产品、功能或增强功能的想法转移到您的产品中,然后将该产品推向市场。好消息是你可以全程使用故事和讲故事。我保证依靠故事和讲故事将帮助你一路走来。
The original idea of stories was pretty simple—write something on a card, talk about it, and agree on what to build. Then, complete the cycle by building it and learning from what you’ve built. That’s it—pretty straightforward, right? If you’ve been involved in software development for even a small amount of time, you know nothing is that simple. Stories go through a long journey with lots of conversations involving lots of people to move an idea for a product, feature, or enhancement into your product, and then move that product out to market. The good news is you can use stories and storytelling all the way through. And I promise that relying on stories and storytelling will help you all the way through.
我通过谈论 Sydnie 的蛋糕和突破的想法结束了最后一章蛋糕变成小蛋糕。但软件的有形性要差得多,而且尺寸不能像蛋糕那样以英寸、厘米、盎司或克来衡量。
I ended the last chapter by talking about Sydnie’s cake and the idea of breaking big cakes into little cakes. But software is a lot less tangible, and size can’t be measured in inches, centimeters, ounces, or grams like it can with a cake.
最初的想法是,用户或需要某物的人可以在卡片上写下他需要的东西,然后我们可以就此进行对话。需要它的人不知道如何将他的需求表达为只需要很短时间就能形成的东西。它需要大小。
The original idea was that a user or a person who needs something could write what he needed on a card and then we could have a conversation about that. The person who needed it didn’t figure out how to express his need as something that would take only a short time to develop. It was need sized.
从用户的角度来看,大小合适的故事是满足需求的故事。
A right-sized story from a user’s perspective is one that fulfills a need.
到了编写软件的时候,编写、测试和集成软件的小部分有很大好处。如果我能更快地看到和测试小零件,我就能衡量我们建造的速度和我们获得的质量。如果我可以将大的东西分成许多小的部分,那么我的团队就可以更容易地同时挑选和构建零件。一个好的经验法则是将故事分解成需要几天时间来构建和测试的东西。
When it comes time to write software, there’s big benefit in writing, testing, and integrating software in small parts. If I can see and test small parts sooner, I can measure how fast we’re building and what kind of quality we’re getting. If I can divide something big into lots of smaller parts, it makes it a little easier for my team to pick up and build parts concurrently. A good rule of thumb is to break down stories to something that takes a couple of days to build and test.
从开发团队的角度来看,一个大小合适的故事只需要几天的时间来构建和测试。
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
但是,从商业角度来看,以多种功能捆绑的形式向客户和用户发布软件可能是最有意义的。如果您要发布一个全新的产品,那么第一个捆绑包可能会非常大。这是我之前称为最小可行解决方案的捆绑包,它专注于为目标用户群实现特定结果。理想情况下,企业应该努力更频繁地发布更多这些内容——以推动它们更接近于匹配用户的需求规模,或者更小、更具体的业务成果。但是,如果您有大量不同的客户使用您的产品,并且您没有支持更连续的发布过程的基础架构或业务模型,那么您的业务发布可能会更大。
But, from a business perspective, it may make the most sense to release software to customers and users in bundles of multiple features. If you’re releasing a whole new product, that first bundle can be pretty large. This is the bundle I called a minimum viable solution earlier, and it’s focused on reaching specific outcomes for a target group of users. Ideally, businesses should be striving to release more of these more frequently—to push them closer to matching users’ need size, or a smaller and more specific business outcome. But, if you’ve got a large, diverse group of customers using your product, and you don’t have an infrastructure or business model that supports a more continuous release process, then your business’s releases may be bigger.
从业务角度来看,大小合适的故事可以帮助企业实现业务成果。
A right-sized story from a business perspective is one that helps a business achieve a business outcome.
我可以说故事没有“合适的大小”,但事实并非如此。合适的尺寸是与您正在进行的对话相关的尺寸。
I could say there’s no “right size” for stories, but that’s not true. The right size is the size that’s relevant to the conversation you’re having.
这些大故事包含许多小故事,小故事又包含更多小故事。根据您的谈话对象,您可能必须将谈话“卷起”到更高的层次。
Those big stories contain lots of smaller stories, which in turn contain lots more smaller stories. Depending on who you’re talking to, you might have to “roll up” your conversation to a higher level.
把故事想象成岩石。如果我拿一块非常大的石头,把它放在地板中间,然后用木槌敲打它,让它裂成 30 块,我们就称那 30 块石头为石头。如果你拿起其中一块较小的石头并用木槌敲打它,它就会碎成小块。我们也称这些作品为岩石。现在,我们可能会对给这些岩石起的名字变得有创意,比如boulder或pebble。但我不确定什么时候某样东西不再是一块巨石,而开始只是一块普通的老石头。它看起来像一块石头,直到它落在你的脚上。然后感觉就像一块巨石。
Think of stories like rocks. If I were to take a really big rock and put it in the middle of the floor and hit it with a mallet where it broke into 30 pieces, we’d call those 30 pieces rocks. If you took one of those smaller rocks and hit it with a mallet, it would break into smaller pieces. We’d call those pieces rocks, too. Now, we might get creative about the names we give these rocks, like boulder or pebble. But I’m never sure when something stops being a boulder and starts being just a plain old rock. It looks like a rock until it’s dropped on your foot. Then it feels like a boulder.
我的破石工具是一把大木槌。这很有效。
My rock-breaking tool is a big mallet. And that works pretty well.
大故事分解成小故事,小故事又可以分解成更小的故事。就像岩石一样。而且,无论大小如何——无论多小——它们仍然是一个故事。但是,我们用来分解故事的最佳工具是什么?没错:这是对话。有时只需要一点点思考就可以做到,但如果您与其他人进行对话和协作,那么您就是在传播共同的理解。
Big stories break down into smaller stories, and those smaller stories can be broken down to even smaller stories. Just like rocks. And, at every size—no matter how small—they’re still a story. But what’s the best tool we use for breaking down stories? That’s right: it’s conversation. Sometimes just a little thinking will do it, but if you use conversation and collaboration with someone else, then you’re spreading the shared understanding.
对话是分解大故事的最佳工具之一。
Conversations are one of the best tools for breaking down big stories.
现在软件人员,我也是其中之一,对这里缺乏精确性感到不舒服。在我合作过的大多数组织中,都会出现按大小对故事进行分类的语言。但它又开始提出“巨石与鹅卵石”的问题。当你是一个被石头砸中的人时,关于大小的精确度最重要,这可以解释为什么软件人员热衷于对他们的故事进行分类。
Now software people, and I’m one of them, are uncomfortable with the lack of precision here. In most organizations I’ve worked with, language will emerge to classify stories by size. But it starts to raise the “boulders versus pebbles” question again. The precision about size matters most when you’re the one being hit with the rock, which could explain why software people get wrapped up in classifying their stories.
如果你在你的组织中创造语言,不要试图过于精确。关于故事中的内容以及它应该有多大的摆动是有意的。它为我们提供了在整个开发周期中使用这个简单想法所需的灵活性。
If you create language in your organization, don’t try to be too precise. The wiggliness about what’s in a story and how big it should be is intentional. It gives us the flexibility we need to use this simple idea throughout the development cycle.
史诗是一个常用术语(我不确定最初是谁创造的)用于描述大用户故事,有点像boulder是大石头的好用词。老实说,我花了很多年才习惯将我们正在构建的重要内容称为故事,但我现在明白为什么要这样称呼它们了。我仍在为epic一词而苦苦挣扎。我听到我的英语文学老师将史诗描述为一个英雄与邪恶作战的故事——比如贝奥武夫、阿喀琉斯或佛罗多——通常是在某种魔法武器或众神的帮助下。但是,我离题了……
Epic is a common term (I’m not sure who coined it originally) used to describe big user stories, sort of like boulder is a good term for a big rock. Now I’ll be honest with you that it took me years to get comfortable referring to the important stuff we were building as stories, but I understand now why they’re called that. I’m still struggling with the term epic. I hear my English Literature teacher describing an epic as a story about a hero battling evil—like Beowulf or Achilles or Frodo—usually with some sort of magic weapon or the assistance of the gods. But, I digress…
史诗是一个我们期望很大的故事,并且知道需要分解。
An epic is a story that we expect is large, and know needs to be broken down.
为一个大故事取一个术语是可以的,但要小心。史诗一词有时被用作武器。我经常看到一个开发团队成员告诉某个业务人员、产品经理、用户或有求必应的人,他的故事是史诗,而不是故事。这通常是以一种表明故事作者做错了什么的语气说的,导致她认真考虑对开发团队成员进行打击。所以,如果你是团队成员,请不要用史诗这个词来训斥别人。对于应该富有成效的对话来说,这是一个糟糕的开始(而且可能是过早的结束)。
It’s OK to have a term for a large story, but watch out. The term epic sometimes gets used as a weapon. I’ve often seen a development team member tell someone who is a businessperson, a product manager, a user, or someone who’s asking for something, that his story is an epic, not a story. This is usually said in a tone that indicates the storywriter has done something wrong, causing her to seriously consider sucker-punching the development team member. So, please, if you are a team member, don’t use the term epic as a stick to reprimand someone else. It’s a bad start (and, possibly, a premature ending) to what should be a productive conversation.
请记住,史诗是大故事,从业务、客户或用户的角度来看可能大小合适——而不是从开发的角度来看。共同努力打破他们。但是要保留史诗,因为你需要和人们谈论它,以及它分解成的所有详细故事。
Remember, epics are big stories that may be the right size from a business, customer, or user perspective—just not from a development perspective. Work together to break them down. But keep the epic around because you’ll need to speak to people about it, and all the detailed stories it broke down into.
如果您使用的是支持敏捷开发的电子工具,它可能会使用史诗的概念作为可以拆分为许多较小的子故事的大父故事。
If you’re using an electronic tool that supports Agile development, it’ll likely use the concept of an epic as a big parent story that can be split up into lots of smaller child stories.
使用术语主题来描述一组故事,将它们组合在一起很有用。当你开始打破常规——分解那些大故事并将它们组织成人们想要、可以使用并且有能力建造的产品——你最终会得到许多小故事。我认为主题是一个袋子,我可以用它来收集一堆相关的故事。我可以使用主题来收集下一个版本所需的一堆故事、同一功能的一部分、与特定类型的用户相关或以其他方式相关。但我的比喻有点不对劲,因为同一个故事可以有两个不同的主题,但同一块石头不能放在两个不同的袋子里。
Use the term theme to describe a group of stories that it’s useful to group together. As you start rock breaking—breaking down those big stories and organizing them into products that people want, can use, and can afford to build—you’ll end up with lots of smaller stories. I think of a theme as a sack I can use to collect a pile of stories that are related. I could use a theme to collect a bunch of stories that are needed for a next release, part of the same feature, relevant to a particular type of user, or related in some other way. But my metaphor is slightly broken since the same story can be in two different themes, but the same rock can’t be in two different sacks.
如果您使用帮助组织敏捷故事组的可用工具之一,它可能支持将故事捆绑成一个主题的概念。您可能只是根据主题的实际情况来引用主题:您的下一个版本、功能或与特定类型用户相关的故事。
If you use one of the available tools that help organize groups of Agile stories, it may support the concept of bundling stories up into a theme. You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.
术语史诗和主题已经进入敏捷生命周期管理工具,进入一些特定的命名敏捷方法,并进入用于讨论故事的通用语言。因此,您需要了解并理解它们。
The terms epic and theme have found their way into Agile lifecycle management tools, into some specific named Agile approaches, and into the common language used to discuss stories. For that reason, you’ll need to know and understand them.
现在,让我们搁置这些条款;忘了我什至提到过他们。至少有一小会儿。让我们退后一步,看看整个破土动工的生命周期。在那个周期中,我们将从大创意开始,您可以将其视为大石头,然后将它们一直移动到小块工作软件。然后将这些小块的工作软件重新组合成客户和用户想要的功能、产品和版本。
Now, let’s set aside those terms; forget I even mentioned them. At least for a little while. Let’s step back and take a look at the whole rock-breaking lifecycle. In that cycle we’ll start with big ideas, which you can think of as the big rocks, and move them all the way through to small pieces of working software. And then reassemble those small pieces of working software into features, products, and releases that customers and users want.
从远处看,这个破岩循环看起来像这样:
From a distance, that rock-breaking cycle looks like this:
现在,让我们深入了解细节。
Now, let’s dig into the details.
故事的旅程始于一个想法。它可能是新功能或全新产品的想法。这可能是我们希望改进我们已有功能的更改。这可能是我们需要解决的问题。但我会使用机会这个词,因为它是我们创造我们将从中受益的东西的机会。我建议您列出并列出这些机会。我称它们为机会积压。
The story’s journey starts as an idea. It may be an idea for a new feature, or a whole new product. It could be a change we’d like that would improve a feature we already have. It could be a problem we need to solve. But I’ll use the term opportunity, because it’s an opportunity for us to make something that we’ll benefit from. I suggest you name and build a list of these opportunities. I call them an opportunity backlog.
我们的第一个好故事对话是一个更高层次的、谁-什么-为什么的讨论。我们的大目标是做出走/不走的决定。Go 并不意味着我们会构建它。这意味着我们将继续进行更深入的讨论,以真正理解这个故事。但如果我们从一开始就发现这是个坏主意,我不想继续花费大量时间来做这件事。No-go 是一种礼貌的表达“垃圾”的方式。所以,让我们称之为前进/垃圾决定。记住,总是有太多东西需要建造,在浪费每个人太多时间之前扼杀一个平庸的机会应该值得庆祝。
Our first good story conversation is a higher-level, who-what-why discussion. And our big goal is to make a go/no-go decision. Go doesn’t mean we’ll build it. It means we’ll go forward with deeper-dive discussions to really understand the story. But I don’t want to move forward with spending lots of time doing this if we can detect that it’s a bad idea from the outset. No-go is a polite way of saying “trash.” So, let’s call this a go-forward/trash decision. Remember, there’s always too much to build, and killing a mediocre opportunity before it wastes too much of everyone’s time should be celebrated.
利用机会讨论来同意问题值得解决——做出继续或垃圾决定。
Use opportunity discussions to agree the problem is worth solving—to make a go-forward or trash decision.
既然您已选择继续前进,那么是时候进行更深入的挖掘了。使用发现来找到值得构建的解决方案。并且不要忘记真正最小化该解决方案。力求使它尽可能小而有价值。
Now that you’ve chosen to go forward, it’s time to dig much deeper. Use discovery to find a solution worth building. And don’t forget to really minimize that solution. Seek to make it as small and valuable as you can.
在发现过程中,您将真正深入挖掘:
During discovery you’ll really dig deep into:
有大量的实践可以在发现过程中提供帮助,尤其是故事映射。故事映射可以帮助您了解当今人们的工作方式,然后映射您关于创建解决方案后事情将如何改变的想法。
There are a huge number of practices that can be helpful during discovery, especially story mapping. Story mapping can help you understand how people work today, and then map your ideas about how things will change for them after your solution is created.
发现是认真研究我们的假设并努力验证它们的关键所在。这可能会采取更深入的分析形式,以了解业务规则或外部法规。它应该采取直接花时间与客户和用户交流的形式,以了解他们的工作方式。它应该涉及构建解决方案的原型并与目标受众一起验证它们。它还应包括构建技术原型以排除技术风险。
Discovery is where it’s critical to look hard at our assumptions and to do work to validate them. This may take the form of deeper analysis to understand business rules or outside regulations. It should take the form of spending time directly with customers and users to understand how they work. It should involve building prototypes of your solution and validating them with your target audience. And it should include building technical prototypes to chase out technical risks.
使用发现对话和探索来找到一个小的、可行的解决方案。
Use discovery conversations and exploration to find a small, viable solution.
庆祝该解决方案中您可以安全丢弃的每一部分,或者将积压的机会推迟到其他地方处理。我们的机会可能是大石头。但这些岩石里面是钻石和贵金属。分解那些石头,把那些真正有价值的部分从那些只是石头的东西中分离出来。并庆祝扔掉那些东西。
Celebrate every part of that solution that you can safely trash, or push back to a backlog of opportunities to deal with elsewhere. Our opportunities may have been big rocks. But inside those rocks were diamonds and precious metals. Break down those rocks and separate those really valuable parts from the stuff that’s just rock. And celebrate trashing that stuff.
在整个发现过程中,您可以选择构建有助于您学习的小东西——特别是 UI 或架构原型。
Throughout discovery, you may choose to build small things that help you learn—specifically, UI or architectural prototypes.
Spike是一个术语,用于表示我们以明确的学习目标进行的一些开发或研究。这是一个来自极限编程社区的术语,用于描述可能不会产生我们选择发布的软件的工作。使用故事来描述让你的团队构建一些东西来学习的峰值。
Spike is a term used for bits of development or research we do with the explicit goal of learning. It’s a term that came from the Extreme Programming community to describe work that may not yield software we choose to ship. Use stories to describe spikes that get your team building something to learn.
在您确信您已经获得了应该构建并发布给客户和用户的故事的一小部分之后,就该将它们推进到交付阶段了。导致有价值的产品发布的故事子集就是我所说的发布积压。
After you’re confident you’ve got that small subset of stories you should build and release to customers and users, then it’s time to move them forward into delivery. That subset of stories that leads to a valuable product release is what I refer to as a release backlog.
我们的机会可能始于大石头。发现对话打破了它们并将岩石与贵金属分开。但是,如果我们能够将这些部分分解成尽可能小的部分,那么交付将以最快和最有效的方式进行——请记住,每个部分仍然需要是我们可以构建和学习的东西。要做到这一点,需要进行更多的对话,深入得多。
Our opportunities may have started as big rocks. Discovery conversations broke them down and separated the rock from the precious metals. But delivery will move fastest and most effectively if we can keep breaking down those pieces into the smallest parts possible—keeping in mind that every part still needs to be something we can build and learn from. It’s going to take a lot more conversations that dive into a lot more depth to do that.
我想象一台很酷的岩石破碎机:我在一侧装载这些包含所有贵金属的大而粗糙的岩石,然后在另一侧吐出大小恰到好处的小岩石,准备进入下一个开发周期。我要给这台机器贴上故事车间机器的标签,它的名字准确地描述了我们将要做的事情。
I picture a cool rock-breaking machine: on one side I load these big, rough rocks that contain all those precious metals, and then the other side spits out small, just-right-sized rocks ready to go into the next development cycle. I’m going to label this machine the story workshop machine, and its name describes exactly what we’ll do.
我们将与开发人员和测试人员以及团队中将构建软件的其他人进行深入讨论,以真正挖掘细节。这些是我们“最后的最佳对话”——我们真正需要就确认达成一致的对话,或我们构建的软件的小部分的验收标准——因为下一步是构建它们。因为我们知道它是打破软件的对话,所以我们将使用这些对话将我们的故事调整到合适的大小和形状,以放入下一个开发冲刺或迭代。
We’ll use deep-dive discussions with developers and testers, and everyone else on the team who’ll build the software, to really dig into the details. These are our “last best conversations”—the conversations where we really need to agree on confirmation, or the acceptance criteria for the small parts of software we build—because the next step is building them. Since we know that it’s conversations that break up software, we’ll use these conversations to get our stories into the right size and shape to put into the next development sprint, or iteration.
使用深度故事研讨会来讨论细节、分解故事,并就我们将要构建的具体内容达成真正一致。
Use deep-dive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.
我喜欢将这些最后的最佳故事对话称为故事工作坊,因为每个人都知道会议没有效率,但研讨会是为了完成工作。它们可以根据需要发生,几乎每天都会发生。有时它们会在计划会议期间同时发生。在敏捷流程 Scrum 中,它们可能发生在所谓的待办事项梳理或待办事项改进会议期间。不管你怎么称呼这些讨论,都进行讨论。
I like to call these last best story conversations story workshops because everyone knows that meetings are unproductive, but workshops are for getting work done. They can happen as needed, almost every day. Sometimes they happen all at once during a planning session. In the Agile process Scrum, they may happen during what’s called a backlog grooming or backlog refinement session. Whatever you call these discussions, have them.
故事车间机器为下一个生产线——敏捷交付机器提供动力。这就是我想象的敏捷交付机器真正发挥作用的地方。我们在一侧放置这些小的、常规大小的故事,而在另一侧放出一个经过优化的、可工作的软件——或者你的故事所描述的任何东西。
The story workshop machine feeds the next in line—the Agile delivery machine. And here’s where I picture the Agile delivery machine really kicking in. In one side we put these small, regular-sized stories, and out the other side comes a polished, working bit of software—or whatever it is that your story described making.
无论您多么努力,即使是您最近的最佳故事对话也无法预测您在开始构建后将学到的一切。计划每天进行大量频繁的临时故事对话。在日常站立会议中提出对它们的需求。
No matter how hard you try, even your last best story conversations won’t have predicted everything you’ll learn once you start to build. Plan to have lots of frequent, ad hoc story conversations every day. Bring up the need for them in your daily standup meetings.
如果您是一名开发人员,并且您陷入故事讨论中的细节不足以回答您现在的问题,请跳起来找人交谈以继续您的讨论。你不能在这里责怪糟糕的要求。请记住,在开始之前,您与其他人一起确定了构建所需的所有知识。但我们都是人。错过一些东西是可以的。
If you’re a developer and the details you trapped in story discussions aren’t enough to answer questions you have now, jump up and find someone to talk with to continue your discussion. You can’t blame bad requirements here. Remember that, before you started, you worked with others to identify all you’d need to know to build. But we’re all human. It’s OK to miss some things.
如果您是产品负责人、用户体验设计师、业务分析师或其他帮助决定构建内容的人之一,请不要害怕从办公桌上站起来查看开发进展情况。我保证,一旦您看到有用的东西,您就会看到有用的东西。而且,更有可能的是,使它工作的人可以使用一点反馈。
If you’re a product owner, UX designer, business analyst, or one of the other folks who helped decide what to build, don’t be afraid to get up from your desk to see how development is going. I promise that once you see something working, you’ll see something useful. And, more than likely, the person getting it working could use a little feedback.
在构建过程中使用对话来填写详细信息并对正在构建的内容提供反馈。
Use conversations as you build to fill in details and give feedback on what’s being built.
当那些完成的工作软件从敏捷交付机器中滚出来时,是时候让那些帮助描述要构建什么的人和构建它的人停下来仔细看看我们构建的东西了。
When those finished bits of working software roll out of the Agile delivery machine, it’s time for the people who helped describe what to build, and the people who build it, to pause and look closely at what we built.
请记住,这些并不是真正的机器。你和你的同事都不是机器上的齿轮。而你刚刚发现的所有这些部分并不是完全相同的小部件。他们都是不同的。
Remember, these aren’t really machines. And you and the people you work with aren’t cogs in a machine. And all those pieces you just turned out aren’t exactly the same widget. They’re all different.
停下来真正看看构建的解决方案的质量。反思你的计划有多有效。你真的完成了你的预期吗?需要更长的时间吗?更短?或者关于你的想象?并真正谈论“机器”的工作情况。是时候对您的工作方式进行调整或改变,以更可预测地获得质量更好的东西了。
Stop and really look at the quality of the solution built. Reflect on how effectively you planned. Did you really finish what you expected? Did it take a lot longer? Shorter? Or about what you imagined? And really talk about how well the “machine” is working. It’s time to make adjustments or changes to the way you work to get better-quality stuff out more predictably.
经常反思产品质量、您的计划和您的工作方式。
Frequently reflect on product quality, your plans, and the way you work.
Scrum 中的第一次评估称为冲刺评审和回顾。无论您将这些时间称为停下来、回顾和反思,请确保您拥有它们。
This first pass at evaluation in Scrum is called a sprint review and retrospective. Whatever you call these times to stop, review, and reflect, make sure you have them.
请记住,您正在构建的内容不适合您——至少通常不适合您。您需要将它展示在用户和客户面前,以了解他们的感受。对于这些人中的一些人,他们所看到的只是原型、线框图或文字描述。看到和触摸到有用的东西,真的可以让他们评估自己是否得到了正确的东西。
Remember that what you’re building wasn’t for you—at least not usually. You’ll need to get it in front of users and customers to see how they feel about it. For some of these folks, all they’ll have seen is a prototype, or a wireframe, or a textual description. Seeing and touching something working really lets them evaluate whether or not they’ve got the right thing.
但是从敏捷交付机器中出来的这些小碎片中的每一个都可能不足以让他们分辨。在我的心智模型中,我想象每一块都在一个秤上堆积起来。这是一种老式秤,另一边有配重。在我的配重上是足够的这个词;也就是说,足以与用户和客户进行测试,并让他们和我们学到一些东西。
But each of these little pieces that came out of the Agile delivery machine may not be enough for them to tell. In my mental model I picture each of those pieces piling up on a scale. It’s one of those old-style scales with a counterweight on the other side. On my counterweight is the word Enough; that is, enough to test with users and customers and for them and us to learn something.
通常足够意味着整个屏幕或屏幕流,允许用户完成任务或达到有意义的目标。而且我不想做一个节目并告诉用户。我不是要他们说,“那太好了。” 我正在寻求学习——学习的形式通常是“这不太对”和“现在我真的在使用它,如果……会更好”
Usually enough means a whole screen, or a flow of screens, that allows users to complete a task or reach a meaningful goal. And I don’t want to do a show and tell with users. I’m not looking for them to say, “That’s great.” I’m looking to learn—and learning usually takes the form of “That’s not quite right” and “Now that I really use it, it would be better if…”
通过与客户和用户一起测试有意义的工作软件块来学习。
Learn by testing meaningful chunks of working software with customers and users.
您的组织中可能还有其他人对您正在构建的软件有既得利益。他们可能不是每天都会使用它的人,但他们担心软件会尽快交付给这些人——或者至少在你说的时候。
There are likely others in your organization who have a vested interest in the software you’re building. They may not be the people who’ll use it every day, but they’re concerned that the software is going to be delivered to those people as soon as possible—or at least when you said it would be.
使用评论向他们展示到目前为止的产品。使用评论来谈论您与更大计划的关系。请记住:他们可能对您是否满足了您构建的一堆单个小零件的计划不感兴趣。他们感兴趣的是最小可行解决方案的进展——因为这是我们可以发布并真正从外部世界获得一些价值的最小部分。所以说那个。与他们分享您对用户或客户进行的测试的结果。他们也会有兴趣了解这一点。
Use a review to show them the product so far. Use the review to talk about where you are in relationship to your bigger plan. Remember: they likely aren’t interested in whether you meet your plan for the bunch of single, small parts you built. What they’re interested in is progress on the minimum viable solution—because that’s the smallest part we could release and really get some value from in the outside world. So speak to that. Share with them the results from tests you’ve done with users or customers. They’ll be interested in learning that, too.
让组织内部的利益相关者看到您的进度和质量。
Keep your progress and quality visible to stakeholders inside your organization.
我在所有这一切结束时想象了最后一个规模。在这个规模上,我把我们一起审查过的部分堆积起来,与客户和用户一起测试,并让我公司的利益相关者看到。巧合的是,这个量表与我们在几步之前使用的量表非常相似——与用户和客户一起评估。与另一个秤一样,在配重上它表示“足够” ——但这次它意味着足以释放给那些客户和用户以产生我正在寻找的结果。当规模达到平衡时,将其发布给客户和用户。
I picture one last scale at the end of all this. On this scale I pile up the parts we’ve reviewed together, tested with customers and users, and made visible to stakeholders in my company. Coincidentally, this scale is very similar to the one that we used a couple of steps ago—evaluate with users and customers. As with this other scale, on the counterweight it says Enough—but this time it means enough to release to those customers and users to produce the outcome I’m looking for. When that scale balances, release it to customers and users.
但不要就此止步。你还有东西要学。如果您像第 3 章中的埃里克一样,学习是您的主要目标,那么您将需要使用指标来了解人们是否以及如何使用您的产品。您需要使用面对面的对话来了解他们为什么使用或不使用它。如果您预测人们会使用您的产品,并且他们和您的公司将从中受益,请不要只是假设。使用指标和对话来真正了解正在发生的事情。
But don’t stop there. You’ve still got something to learn. If you were like Eric in Chapter 3, learning was your primary goal, so you’ll need to use metrics to learn if and how people use your product. You’ll need to use face-to-face conversations to learn why they do or don’t use it. If you predicted that people would be using your product, and they and your company would be benefiting from it, don’t just assume that. Use metrics and conversations to really learn what’s happening.
使用指标和与用户面对面的时间来真正了解您的目标结果是否达到。
Use metrics and face time with users to really learn if your target outcomes were met.
如果这是一个项目,你就完成了——因为你交付了它。但你刚刚做了一些事情。这是一个产品。产品的生命从交付之时就开始了。当你开始关注人们用你的产品做什么时,我保证你会找到改进它的机会。把它们写下来,并将它们反馈到这个模型的开头。
If this were a project, you’d be done—because you shipped it. But you just made something. It’s a product. And a product’s life starts when it’s delivered. When you start paying attention to what people are doing with your product, I promise you’ll find opportunities to improve it. Write those down, and feed them back into the beginning of this model.
这才是真正的生活循环——或者至少是故事中的生活。
That’s the real circle of life—or at least, the life of a story.
这是一个很大的突破。那么究竟应该由谁来进行所有这些岩石破碎工作呢?很高兴你提出这个问题,因为这就是下一章的内容。
And that’s a lot of rock breaking. So exactly who is supposed to do all that rock breaking? I’m glad you asked, because that’s what the next chapter is about.
在常见的敏捷实践中有一个令人讨厌的错误假设:只有一个人负责编写故事并进行所有这些故事对话。在敏捷过程 Scrum 中,这个人被称为产品负责人。但是,有两个主要原因导致此逻辑不起作用,而且可能还有许多较小的原因。
There’s a nasty misassumption in common Agile practice: that there’s a single person responsible for writing stories and conducting all these story conversations. In the Agile process Scrum, that person is called the product owner. There are two big reasons, however, why this logic doesn’t work, and probably a lot of smaller reasons, too.
要求一个产品负责人编写所有故事并参与所有故事对话是行不通的。
Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.
别误会我的意思。在我对良好产品开发的看法中,产品负责人是关键的领导者。他让产品和整个团队都专注于朝着同一个方向前进。
Don’t get me wrong here. In my vision of good product development, the product owner is a critical leader. He keeps the product and whole team focused on moving the same direction.
替代方案是由委员会设计的——一种非常糟糕的反模式,在这种模式中,每个人对我们所做的事情都有平等的发言权。在委员会中,当我们只有时间和资源做一件事时,我们就会妥协。我和我的前妻在选择餐厅时经常这样做。她想要海鲜,我想要墨西哥菜,我们会选择我们都不喜欢的东西。当一个委员会不受时间和资源的限制时,我们会全力以赴。您使用过这样的软件产品:产品的功能多得数不过来,而您最大的问题是找到功能或记住如何使用它。
The alternative is design by committee—a seriously bad anti-pattern where everyone gets an equal say in what we do. In a committee, when we only have time and resources to do one thing, we compromise. My ex-wife and I would often do this when choosing a restaurant. She wanted seafood, and I wanted Mexican food, and we’d settle on something neither of us liked. When a committee isn’t constrained by time and resources, we do it all. You’ve used software products like this: the product with more features than anyone can count, and where your biggest problem is finding the feature or remembering how to use it.
有效的产品负责人身边都是他们需要做出正确决策的人。他们结合了许多人的专业知识和意见。但是,最终,当资源受限或产品的成功受到威胁时,他们必须做出决定。总会有人对这个决定不满意。我的朋友 Leisa Reichelt 说很好:“社区设计不是委员会设计……设计从来都不是民主的。” [ 12 ]
Effective product owners surround themselves with the people they need to make good decisions. They incorporate the expertise and opinions of many. But, in the end, when resources are constrained or the success of the product is at stake, they must make decisions. And there’s always someone who’ll be unhappy with that decision. My friend Leisa Reichelt puts it well: “Design by community is not design by committee…design is never democratic.”[12]
Marty Cagan在他的著作《灵感:如何创造客户喜爱的产品》(SVPG 出版社)中描述了产品经理识别有价值、可用和可行的产品的责任。当我第一次读到这些话时,我在脑海中描绘了一个简单的维恩图,其中我们想要的解决方案是对我们公司和我们的客户有价值的东西的交集,可供用户使用,并且在我们的时间和工具的情况下是可行的有。
In his book Inspired: How to Create Products Customers Love (SVPG Press), Marty Cagan describes the responsibility of a product manager to identify a product that’s valuable, usable, and feasible. When I first read these words, I pictured in my head a simple Venn diagram where the solution we want is an intersection of what’s valuable to our company and our customers, usable by its users, and feasible to build given the time and the tools we have.
但这里可能不太明显的是,要真正确定处于最佳位置中心的解决方案,需要了解我们的业务、我们的客户、我们的用户和我们使用的技术的人员之间的协作——而不仅仅是了解这些事情,但对解决方案的成功负责。这些人实际上与利益相关者、客户和用户交谈;他们实际设计和测试用户界面;他们实际上设计和测试使产品工作的代码。
But what may not be dead obvious here is that, to really identify the solution in the center of that sweet spot will take collaboration between people who understand our business, our customers, our users, and the technology we use—and not just understand those things, but take responsibility for the success of the solution. These people actually speak with stakeholders, customers, and users; they actually design and test user interfaces; they actually design and test the code that makes the product work.
还记得敏捷开发中的误解,即单个产品所有者或产品经理决定构建什么吗?一个人拥有找到有价值的可用可行最佳点所需的业务、用户界面设计和工程技能,即使不是不可能,也是很少见的。这就是为什么最有效的组织使用小型、跨职能的探索团队来共同寻找正确的解决方案。正如我们在前一章中讨论的那样,将发现视为突破性的工作。我们所做的工作是将一个故事从一个模糊的大想法转变为我们可以构建的小而具体的东西。
Remember that misconception in Agile development where a single product owner or product manager decides what to build? It’s rare if not impossible for a single person to possess the business, user interface design, and engineering skills necessary to find that valuable-usable-feasible sweet spot. That’s why the most effective organizations use small, cross-functional discovery teams that work together to find that right solution. As we discussed in the preceding chapter, think of discovery as rock-breaking work. It’s the work we do to move a story from a big vague idea to something small and specific we can build.
由产品负责人领导的小型跨职能团队协调产品发现工作。
A small, cross-functional team led by a product owner orchestrates product discovery work.
团队的理想规模是 2 到 4 人——晚餐对话的规模,这样成员们可以快速建立共识。
The ideal size for the team is two to four people—dinner-conversation-sized so the members can quickly build shared understanding.
这个团队应该由对她的业务愿景和战略以及她的产品所服务的市场有深刻理解的产品所有者或产品经理领导。这个核心团队包括了解用户、乐于与他们合作以了解他们的工作方式并且可以绘制和创建简单的 UI 原型的人员。它还包括来自将构建产品的团队的高级工程师。此人需要了解系统的当前架构,并深入了解可用于解决棘手问题的新工程方法。这里真正的秘密在于,最具创新性的解决方案通常来自对业务问题和用户问题具有洞察力的工程师。
This team should be led by a product owner or product manager who has deep understanding of her business’s vision and strategy, and of the market her product serves. This core team includes someone who understands users, is comfortable working with them to learn about the way they work, and can sketch and create simple UI prototypes. It also includes a senior engineer from the team who’ll build the product. This person needs to understand the current architecture of the system and have insight into newer engineering approaches that could be used to solve tough problems. The real secret here is that the most innovative solutions often come from the engineer supplied with insight about the business problem and the users’ problems.
一个有凝聚力的发现团队是一个强大的、快速移动的专家组,他们可以快速发现问题并验证解决方案。我经常听到triad这个词来形容这个核心团队。在我最近访问位于悉尼的 Atlassian 时,您在第 8 章中遇到的 Sherif指着三个并排的座位。他解释说,“这就是三合会所在的地方。” 三合会周围的区域摆满了桌子和电脑,团队的其他成员就坐在那里。当发现团队中有两个人、四个人甚至更多人时,我会听到“三合一”一词,因为我们谈论的是三个问题——有价值、可用和可行——而不是三个机构。
A cohesive discovery team is a powerful, fast-moving group of experts who can find problems and validate solutions quickly. I often hear the term triad used to describe this core team. On my recent visit to Sydney-based Atlassian, Sherif, whom you met in Chapter 8, pointed to three seats close together. He explained, “This is where the triad sits.” The area around the triad was filled with desks and computers where the rest of the team sat. I hear the term triad used when there are two people, four people, or even more on the discovery team, since it’s the three concerns—valuable, usable, and feasible—we’re talking about, not three bodies.
通过包括用户体验、设计专业知识和技术专业知识的核心团队为产品所有者提供支持。
Support product owners with a core team that includes user experience, design expertise, and technical expertise.
有效的发现不仅可以协调与开发团队的协作,还可以协调业务利益相关者、主题专家、客户和最终用户的协作。这是一项艰巨的工作,除了每个团队成员带来的特定专业知识外,还需要一流的沟通和协调技巧。
An effective discovery coordinates collaboration with not only the development team, but also business stakeholders, subject matter experts, customers, and end users. It’s tough work that requires top-notch communication and facilitation skills, in addition to the specific expertise each team member brings in.
现在,这是真正的秘密。对于任何重要的产品,都需要一个团队来构建它。为了保持产品愿景清晰,确保团队构建的解决方案具有凝聚力,并帮助每个人朝着同一个方向前进,好的产品领导者至关重要。这些领导者中的佼佼者专注于帮助每个人掌握主人翁精神。在一个健康的故事驱动的环境中,你会看到很多故事对话一直在进行。他们中的许多人不需要那里的产品负责人。
Now, here’s the real secret. For a product of any significance, it’ll take a team to get it built. To keep the vision of the product clear, ensure the solution the team builds is cohesive, and help keep everyone moving in the same direction, a good product leader is critical. The best of these leaders focus on helping everyone take ownership. In a healthy story-driven environment, you’ll see lots of story conversations going on all the time. And many of them won’t need the product leader there.
¡三个朋友!是 1986 年一部平庸的西部喜剧的名字,由 Steve Martin、Chevy Chase 和 Martin Short 主演。这部电影与敏捷软件开发和故事有什么关系?在故事研讨会期间,有一个更具战术性的合作者三合会很有价值。我不确定最初是谁给他们起了“三个朋友”的绰号,但是它似乎卡住了。[ 13 ](我敢肯定,如果有更多人看过这部电影,那就不会了。)
¡Three Amigos! is the name of a mediocre 1986 western comedy starring Steve Martin, Chevy Chase, and Martin Short. What does this film have to do with Agile software development and stories? There’s a more tactical triad of collaborators that’s valuable during story workshops. And I’m not sure who originally gave them the moniker “the three amigos,” but it appears to have stuck.[13] (I’m sure if more people had seen the movie, it wouldn’t have.)
您可能还记得,故事研讨会是我对最后一次最佳对话的术语,在对话中我们具体决定要构建什么。这就是三个朋友进来的地方。
You might recall that story workshops is the term I give to that last best conversation where we decide specifically what to build. It’s here where the three amigos come in.
在最后一次最好的谈话中,我们确实需要考虑很多细节和实施的备选方案,因此我们需要团队中的一名开发人员来构建软件——理想情况下,是真正从事该软件工作的开发人员之一。
During this last best conversation, we really need to consider lots of details and alternatives for implementation, so we’ll need a developer from the team who’ll build the software—ideally, one of the developers who will actually work on it.
为了让这个小软件被认为已经完成,它需要进行测试,所以我们需要一个测试人员参与对话。测试人员——第一个朋友——通常会以批判的眼光看待讨论,比大多数人更早发现可能出错的地方。测试人员通常最擅长玩“What-About”游戏。
For this small piece of software to be considered done, it’ll need to be tested, so we’ll need a tester in the conversation. A tester—the first amigo—will often bring a critical eye into the discussion, spotting things that might go wrong sooner than most. The tester is often the best at playing the “What-About” game.
而且,当然,我们需要有人了解我们正在构建什么、它的用途以及我们为什么要构建它,因此我们需要该核心产品发现团队的一名成员。那个人就是第二个朋友。
And, of course, we’ll need someone who understands what we’re building, who it’s for, and why we’re building it, so we’ll need a member of that core product discovery team. That person is the second amigo.
在这个阶段,我们通常不会引入新的功能创意。我们可能已经在发现中这样做了。现在我们或多或少地致力于构建一些东西,所以明确了解该软件的外观和行为方式非常重要。因此,参与此对话的人通常是处理过这些细节的用户体验设计师或业务分析师。这是你的第三个朋友。
At this stage we’re often not introducing a new feature idea. We likely already did that back in discovery. Now we’ve more or less committed to build something, so it’s important to understand specifically how that software should look and behave. So often the person involved in this conversation is a user experience designer or business analyst who’s worked through those details. This is your third amigo.
该小组将研究细节并就故事的具体验收标准达成一致。通过这次对话,我们将对构建和测试软件所需的时间做出最佳估计。正是在这种对话中,我们经常决定将故事拆分为更小的、“大小合适”的开发故事——这些故事需要一到三天的时间来构建和测试。
This group will work through the details and agree on specific acceptance criteria for the story. It’s out of this conversation that we’ll have our best estimate of how long it will take to build and test the software. And it’s often in this conversation that we’ll make decisions to split the story into smaller, “right-sized” development stories—those stories that take one to three days to build and test.
当我们通过软件开发传递想法时,故事对话会不断发生。在每次谈话中,把有价值的、有用的、可行的都保留在讨论中。包括可以与这些事物交谈的人。通过让产品所有者对成功的、有凝聚力的产品负责来避免由委员会进行设计。
Story conversations happen continuously as we move ideas through software development. In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by holding a product owner responsible for a successful, cohesive product.
如果您在更传统的 IT 环境中工作,产品负责人的概念可能看起来令人困惑。例如,如果您帮助银行构建关键系统,银行就会知道其真正的产品是向客户销售的银行服务。如果有人的正式头衔是“产品经理”,那么他的工作就是管理特定类型的银行账户或信贷产品。支持该服务产品的计算机系统只是拼图的一部分。通常,相同的 IT 基础架构支持许多不同的银行产品。可以理解的是,该银行并不将该基础设施视为一种产品,而且通常没有人拥有它。
If you work in a more traditional IT setting, the notion of a product owner may seem confusing. For example, if you help build critical systems for a bank, the bank knows its real products are the banking services it sells to its customers. If there is a person with the official title of “product manager,” it’ll be his job to look after a specific type of bank account or credit product. The computer systems that support that service offering are just a piece of the puzzle. And often that same IT infrastructure supports lots of different banking products. Understandably, the bank doesn’t see that infrastructure as a product, and there’s often no one who owns it.
在这些类型的组织中,业务分析师 (BA) 通常担任“需求收集”角色。他们将充当开发人员和业务利益相关者(如银行或保险产品的产品经理)之间的中介。当这些业务人员需要更改支持其产品的 IT 基础架构时,他们将与 BA 一起描述这些更改。这就是他们可能扮演客户角色的地方,因为 BA 扮演供应商角色,这就是反模式发挥作用的地方。
In these types of organizations, business analysts (BAs) are often placed in a “requirements gathering” role. They’ll act as an intermediary between the developers and the business stakeholders like the product manager of a banking or insurance product. When those businesspeople need changes to the IT infrastructure that supports their product, they’ll work with the BA to describe those changes. And here’s where they might take on the client role as the BA acts in a vendor role, and that’s where the anti-pattern kicks in.
在闲聊中,我的朋友大卫·哈斯曼 (David Hussman) 给了我一个更好的比喻来说明文学士与其业务利益相关者之间的关系——就像音乐制作人与乐队之间的关系一样。这对 David 来说是有道理的,他既是 Agile 大师,又是 1980 年代重金属乐队 Slave Raider 的前吉他手。他曾与制片人合作,自己也是制片人。在这种关系中,乐队带着激情进入音乐行业,希望有一些天赋,但他们不了解音乐行业或录制专辑的技巧。然而,生产者确实如此。制作人的工作就是帮助乐队录制出最成功的唱片。成功的制作人可以将才华横溢的天才变成具有商业可行性的唱片艺术家。
In casual conversation, my friend David Hussman gave me a better metaphor for the relationship the BA should have with his business stakeholders—the same relationship that a music producer has with a band. This makes sense coming from David, who’s both an Agile guru and ex-guitarist for the 1980s heavy metal band Slave Raider. He’s worked with producers, and been a producer himself. In that relationship the band comes to the music business with passion, and hopefully some talent, but they don’t know the music business or the mechanics of recording an album. The producer does, however. It’s the producer’s job to help that band make the most successful recording it can. Successful producers can turn raw talent into a polished, commercially viable recording artist.
作为 IT 环境中的业务分析师,这就是您的工作。了解您的业务利益相关者的愿景并帮助他们取得成功。你不能只是一个执行命令的人——你需要表现得更像一个医生。有时这意味着告诉您的利益相关者他们不想听到的事情。但是,如果您真诚地帮助他们取得成功,他们会看到并重视您的帮助。
As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make it a success. You can’t be just an order taker—you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want to hear. But, if you’re sincere about helping them succeed, they’ll see it and value your help.
当作为其他利益相关者的想法的产品所有者时,扮演帮助他们成功的生产者的角色。
When acting as product owner for other stakeholders’ ideas, take on the role of a producer who helps them succeed.
一种潜在的反模式是让业务利益相关者承担产品所有权的角色。我说潜力是因为如果业务人员得到其他团队成员的大量帮助和支持,渴望学习如何完成产品负责人的工作,以及完成它所需的时间,它就可以发挥作用。产品所有权不是一项微不足道的责任,不应被视为可以在业余时间完成的事情。与其强迫商人从事另一份工作,我建议您为他们找一个制作人来帮助他们取得成功。
One potential anti-pattern is to make the business stakeholder take on the product ownership role. I say potential because it can work if the businessperson has lots of help and support from other team members, an aspiration to learn how to do the job of a product owner, and the time it’ll take to do it. Product ownership isn’t a trivial responsibility, and shouldn’t be treated as something that could be done in your spare time. Instead of forcing another job on businesspeople, I’d recommend you find them a producer to help them succeed.
对于一个核心很简单的想法,整个故事变得非常混乱。如果有人告诉你软件开发——或任何产品开发,就此而言——很容易,那他们是在撒谎。
For an idea that at its core is simple, this whole story thing has gotten terribly messy. If anyone told you software development—or any product development, for that matter—was easy, they were lying.
故事同时包含很多东西。我们将使用这个词来指代卡片,指代我们构建的软件块,尤其是指我们必须就应该构建什么做出决定的那种对话。故事可以描述非常大的机会,或者本身对客户和用户来说不一定有意义的几乎微不足道的可交付成果。处理故事是一个持续的对话和讨论过程,将故事从大事分解为小事。通过所有这些对话,我们不仅关注我们可以构建什么,而且关注为谁构建以及为什么构建。故事地图只是帮助我们分解大事的方法之一,同时将对话的重点放在使用您产品的人以及他们成功的原因上。
Stories are many things at once. We’ll use the word to refer to the card, to the chunk of software we build, and especially to the kind of conversations we have to make decisions about what we should build. Stories can describe very large opportunities, or the almost insignificant deliverable pieces that by themselves aren’t necessarily meaningful to customers and users. Working with stories is a continuous process of conversation and discussion to break them down from big things to small things. And through all those conversations, we’re keeping not only what we could build in focus, but for whom, and why. Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your product and what makes them successful.
如果这一切都开始变得有意义,那么你已经做出了重大的、必要的思维转变。这不是使用故事来记录需求的转变,而是转向更有效地与人合作,并共同专注于解决您创建的产品的实际问题。
If this is all starting to make sense, then you’ve made that big, necessary mindshift. It’s not a shift to use stories to document requirements, but a shift toward working with people more effectively, and together focusing on solving real problems with the products you create.
而且,我希望你会同意,这是一件美丽的事情。
And that, I hope you’ll agree, is a beautiful thing.
[ 12 ] Leisa Reichelt 最初在 2009 年的 IXDA 演讲中包含了这条宝贵的评论。在此处查看她后来的文章:http ://www.disambiguity.com/designbycommunity/ 。
[12] Leisa Reichelt originally included this gem of a comment in a 2009 IXDA talk. See her later essay here: http://www.disambiguity.com/designbycommunity/.
[ 13 ] Ryan Thomas Hewitt 在 Scrum Alliance 网站上发表的这篇文章解释了三个朋友式的故事研讨会:http ://bit.ly/Utg8er 。
[13] This article on the Scrum Alliance website by Ryan Thomas Hewitt explains a three amigos–style story workshop: http://bit.ly/Utg8er.
让我再次指出故事如何像岩石。就像一块石头,当你把它分成更小的部分时,你也可以称这些部分为“岩石”——只是更小的岩石。但总会有第一块石头。这是我们需要仔细研究的,以决定它是否值得分手。让我们称之为“零摇滚”。在我们的故事流中,我将称之为机会。
Let me point out again how stories are like rocks. And like a rock, when you break it into smaller parts, you can call those parts “rocks” too—just smaller rocks. But there’s always that first rock. That’s the one we’ll need to look closely at to decide if it’s worth breaking up or not. Let’s call it “rock zero.” And in our flow of stories, I’ll call that an opportunity.
我正在利用我们认为可以解决问题的想法的机会。我不仅仅是一个半满的人。只是将每个想法都视为我们需要包含在我们的产品中的东西是一个坏主意,因为您知道没有足够的时间和人员来构建所有这些东西。而且,即使您确实有时间和人员,您的客户也会不知所措。
I’m using opportunity for ideas that we believe will solve a problem. I’m not just a glass-half-full guy. It’s just that it’s a bad idea to consider every idea as something we need to include in our product, because you know that there isn’t enough time and people to build all that stuff. And, even if you did have the time and people, your customers would be overwhelmed.
当我们想出点子时,这些点子往往非常宏大——但并非总是如此。用故事术语来说,你可以称它们为史诗,但我更愿意称它们为机遇。不管你怎么称呼它们,它们仍然是故事,我们关于它们的第一次对话的目的是决定是继续使用它们,还是丢弃它们。对于这些机会中的每一个,我们可以讨论:
When we come up with ideas, these ideas are often pretty big—but not always. In story lingo, you could call them epics, but I prefer to call them opportunities. No matter what you call them, they’re still stories, and the goal of the first conversations we have about them is to decide whether to move forward with them, or trash them. For each one of these opportunities, we can discuss:
这些故事的全部堆栈就是我所说的机会积压。我们还不确定是否应该建造它们,或者至少我们不应该建造它们。请记住,对于构建事物的想法总是比我们有时间的更多。找到与您组织的业务战略相一致的机会,并为客户和用户解决有吸引力的问题。进行足够的讨论以做出通过/不通过的决定。
The whole stack of these stories is what I call an opportunity backlog. We aren’t sure yet if we should build them, or at least we shouldn’t be. Remember, there are always more ideas for things to build than we’ll have time for. Find the opportunities aligned with your organization’s business strategy and that solve problems for customers and users that are compelling. Have enough discussions to make a go/no-go decision.
“开始”并不意味着“我们要建造这个东西”,它意味着我们将把机会推进到更深入的发现讨论中。在发现过程中,需要进行更多的讨论——可能与不在房间里的其他人进行讨论。如果这是一项新功能或全新产品,则需要更深入地了解客户和用户以及他们如何解决当今的问题。理想情况下,我们会直接与他们交谈。这将需要探索和制作不同解决方案的原型。根据您和您的团队所学到的知识,需要进行大量更深入的讨论,才能决定您具体需要构建哪些内容才能对客户、用户和您的组织有价值。而且,在所有这些工作之后,您仍然可能决定扼杀这个想法。
“Go” doesn’t mean “We’re gonna build this thing,” it means we’ll move the opportunity forward into deeper discovery discussion. During discovery, it’ll take a lot more discussion—probably with others not in the room. If this is a new feature or an entirely new product, it’ll take diving a lot deeper into customers and users and how they solve their problems today. Ideally, we’ll talk to them directly. It’ll take exploring and prototyping different solutions. It’ll take lots of deeper discussions in light of what you and your team learn to make a decision about what specifically you’ll need to build to be valuable to customers, users, and your organization. And, after all that work, you still might decide to kill the idea.
“不去”是机会讨论的一个很好的结果。请记住,要建造的东西总是比时间多。如果根据您的讨论,这个机会看起来没有希望,现在就把它扔掉。让支持该想法的人参与讨论可能是个好主意,希望他们能得出相同的结论。
“No-go” is a great result of an opportunity discussion. Remember, there’s always more to build than there is time. If the opportunity doesn’t look promising based on your discussion, trash it now. It may be a good idea to involve the people who championed the idea in the discussion so hopefully they come to the same conclusion.
您的小组可能没有足够的信息来做出继续或不继续的决定。如果是这种情况,请列出您需要学习的内容,然后一起开始工作以获取所需的信息。
Your group may not have enough information to make either a go or a no-go decision. If that’s the case, make a list of what you need to learn, and together get to work getting the information you need.
如果您仍然不能做出继续或不继续的决定,您可以随时将其放回机会待办列表中,稍后再讨论。这就是所谓的拖延症,我经常这样做。
If you still can’t make a go or no-go decision, you can always put it back into the opportunity backlog to discuss later. That’s called procrastination, and I do it a lot.
我知道你的公司可能不会利用机会。事实上,如果你的公司和我合作过的公司一样,你就有了一张路线图,上面写满了你应该构建的东西。您甚至可以将它们视为您的“要求”。对任何这些东西做出不去的决定可能不是你的决定。事实是,我们真的不应该将所有这些聪明的想法都变成软件,无论拥有聪明想法的人的职位是什么。
I know your company probably doesn’t use opportunities. In fact, if your company is anything like those I’ve worked with, you’ve got a roadmap filled with stuff you’re supposed to build. You may even think of them as your “requirements.” Making a no-go decision on any of that stuff may not be your call. The truth is, we really shouldn’t turn all those clever ideas into software, no matter the job title of the person with the clever idea.
使用这第一次重大故事对话来构建您和您的团队可能要从事的工作。即使对通过/不通过问题的答案可能是“开始”,但请确保您在结束对话时就您正在解决的问题、为谁以及您的组织如何从构建软件中获益达成共识。
Use this first big story conversation to frame the work you and your team may be getting into. Even though the answer to the go/no-go question may be “Go,” make sure you leave the conversation with shared understanding about the problems you’re solving, for whom, and how your organization benefits from building software.
如果您或您团队中的任何人都不能决定继续利用这个机会,那么请确保您将可以做出该决定的人包括在对话中。如果他们不可用,无论如何都要进行对话,并对谁、什么以及为什么做出假设。然后与决策者分享这些假设。我向你保证,如果你做错了,他们会纠正你。讨论这些更正将开始正确的对话。
If it’s not your decision, or anyone on your team’s decision, to go ahead with this opportunity, then make sure you include those in the conversation who can make that decision. If they’re not available, have the conversation anyway, and make assumptions about who, what, and why. Then share those assumptions with decision makers. I promise you that they’ll correct you if you’ve got it wrong. Discussing those corrections will start the right conversation.
尽管我喜欢故事地图,但我不会使用地图来管理机会。这些机会通常是更大的块。关于这些大石头的讨论通常会朝着我们需要的细节推进,以便我们决定将它们带入更深层次的发现。
As much as I like story maps, I wouldn’t use a map to manage opportunities. Those opportunities are usually bigger chunks. And discussion about these big rocks usually drives toward the details we’ll need in order to decide about moving them into deeper discovery.
但故事地图擅长的一件事是为您提供了一种真正有效的方式,让您退后一步,查看您现在拥有的产品的全局。使用您今天为您的产品创建的地图来寻找机会,或者考虑您今天的产品背景下已经拥有的机会。
But one thing that story maps are great at is giving you a really effective way to step back and look at the big picture for the product you have now. Use a map you create for your product today to find opportunities, or to consider the opportunities you already have in the context of your product today.
尝试为现有产品构建一个简单的、非常高级的地图。这是一个“现在”地图,类似于您在第 5 章中构建的关于开始您的早晨的地图。(你确实建造了它,不是吗?)这些类型的地图已经以各种形式出现了一段时间。它们通常被称为旅程地图。要为您当前的产品体验制作一张地图,只需绘制用户在他们从事的主要活动中所经历的流程。使用此地图为您的机会提供背景信息。为此,将每个机会添加到地图主体中。使用不同颜色的便利贴或索引卡清楚地标出它们。您可能看到的是机会“热点”——用户流中的想法密度较高且用户可能会感到痛苦的地方。
Try building a simple, very high-level map of your existing product. This is a “now” map similar to the one you built in Chapter 5 about starting your morning. (You did build it, didn’t you?) These types of maps have been around in various forms for a while. They’re often called journey maps. To make one for your current product’s experience, just map the flow users take through the major activities they engage in. Use this map to give context to your opportunities. To do this, add each opportunity into the body of the map. Use a different color of sticky note or index card to clearly call them out. What you might see are opportunity “hot spots”—places in your users’ flow where there’s a higher density of ideas and likely pain from your users.
查看参与每项活动的用户,以及该活动的频率。影响关键用户参与的高频活动的机会很可能是您应该关注的机会——宜早不宜迟。
Look at the users engaged in each activity, and the frequency of that activity. Opportunities that affect high-frequency activities engaged in by critical users are likely opportunities you should be focusing on—sooner rather than later.
您可以使用同一张地图为用户今天抱怨的事情添加卡片。为了平衡事物,看看他们今天喜欢的产品部分,并添加这些乐趣。如果您发现用户有很多痛苦的地方,但您还没有发现任何机会,您可能应该这样做。
You can use this same map to add in cards for the things users complain about today. To balance things, look at the parts of the product that they love today, and add in those joys. If you find places where there’s lots of pain for users, but you haven’t yet identified any opportunities, you probably should.
如果你同意承担一切,你就不是在帮助任何人。积极地丢弃那些对创造你所希望的结果没有多大希望的机会。与业务利益相关者合作来做到这一点,以便他们可以帮助做出这些决定。
You’re not helping anyone if you agree to take on everything. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for. Work with business stakeholders to do this so they can help make those decisions.
如果您做出了前进的决定,那么就该卷起袖子开始工作了。这就是下一章的内容。
If you’ve made a go-forward decision, it’s time to roll up your sleeves and get to work. And that’s what the next chapter is about.
你们中的一些人可能已经阅读了上一章和之前的其他章节,并且您已经慢慢达到沸点,因为您知道我遗漏了什么。对于那个很抱歉。
Some of you may have been reading the last chapter, and other chapters before that, and you’ve been slowly reaching a boiling point because you know what I’m leaving out. Sorry about that.
我讲的关于MadMimi.com和 Globo.com 的故事都不完整。事实是,他们俩都使用发现对话来确定他们认为是最低限度可行的解决方案。但这些解决方案是否真的可行只是一个猜测。事实上,在我们实际发货并观察市场——我们的客户和用户——实际做的事情之前,所有这些都是猜测。最初的发现对话以及故事地图帮助他们进行了良好的初步猜测。但是,对于他们两人来说,这标志着真正发现可行产品的漫长旅程的开始。
The stories I told about MadMimi.com and Globo.com are both incomplete. The truth is that both of them used discovery conversations to identify what they believed was a minimum viable solution. But whether those solutions were actually viable or not was just a guess. In fact, all this stuff is a guess until we actually ship and observe what the market—our customer and users—actually does. Initial discovery conversations, along with story maps, helped them get to a good starting guess. But, for both of them, it marked the beginning of a much longer journey to really discover a viable product.
这导致我犯了人们犯的最大错误之一,实际上是相信他们的最小可行解决方案会成功。
This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.
我和下一个相信我的伟大想法会成功的人一样内疚。事实上,过去我发布了很多我认为会非常成功的解决方案,但事实并非如此。它们也不是令人沮丧的失败——它们只是没有产生太大的影响。发生这种情况时,我和我的公司学会了换个角度看。不仅仅是我。我们都认为我们添加的功能很有价值。但最后我们添加了一些人使用的功能,但大多数人没有,我们知道我们最终会支持我们产品的生命周期。
I’m as guilty as the next guy in believing my great ideas will be successful. The truth is that in the past I released lots of solutions I thought would be wildly successful, but they just weren’t. They weren’t dismal failures, either—they just didn’t make much of a difference. When this happened I, and my company, learned to look the other way. It wasn’t just me. We all thought the features we were adding would be valuable. But in the end we’d added a feature a few people used, but most didn’t, and we knew we’d end up supporting for the life of our product.
我的信念不是基于任何正式的科学研究,而是基于我自己的失败以及我在与其他公司合作时所观察到的,即我们所构建的东西很少是成功的或具有我们希望的真正影响。我估计最多 20%。然后,我们所做的另外 20% 的事情是真正的失败——导致负面影响的解决方案。我见过很多组织发布了一个新的、更好的网站版本,但发现销量下降,或者发布了一个新版本的产品,客户试用后要求退回旧版本。这就是我所说的失败。
My belief, not rooted in any formal scientific research or studies, but just in my own failures and what I observe working with other companies, is that very little of what we build is successful or has the real impact we hope for. I figure around 20 percent max. Then there is another 20 percent of things we do that are genuine failures—solutions that result in a negative impact. I’ve seen a variety of organizations that release a new, better version of their website and see sales decrease, or release a new version of their product that customers try and then demand the old version back. That’s the kind of failure I’m talking about.
但这是中间的 60%,无论是给予还是接受,这既不是成功也不是失败,这才是大问题。这是我们花费宝贵的开发资金创造的东西,最终希望我们没有。
But it’s that 60 percent in the middle, give or take, that is neither success nor failure that’s the big problem. This is the stuff that we spend valuable development money creating, and in the end wish we hadn’t.
Standish Group 发表在历史性“混沌”报告中的研究解释说,64% 到 75% 的功能很少或从未使用过。[ 14 ]而且,根据您查看的来源,75-90% 的软件初创公司都失败了。[ 15 ]
Research from the Standish Group published in historic “Chaos” reports explains that between 64 and 75 percent of features are rarely or never used.[14] And, depending on the source you look at, 75–90 percent of all software startups fail.[15]
当你想到这一切时,这一切都非常令人失望。难怪只是假装它在工作是大多数组织的选择策略。
All this is pretty disappointing when you think about it. No wonder just pretending it’s working is the strategy of choice for most organizations.
在过去糟糕的日子里,我曾经有点像这样工作。我想出了一个好主意,或者实际上是其他人(例如我的首席执行官或重要客户)将他们的好主意交给了我。我会开始努力理解它并充实它。然后我和我的团队会建造它。它总是花费我们预期的两倍时间,但这是一个需要在后面的章节中处理的问题。我们会完成的。我们会发货。我们会庆祝。有时我们庆祝,然后发货。但无论哪种方式,我们都完成了。
In the bad old days, I used to work a bit like this. I’d come up with a great idea, or in reality, someone else like my CEO or a key customer handed me their great idea. I’d get to work making sense of it and fleshing it out. Then my team and I would build it. It always took twice as long as we expected, but that’s a problem to deal with in later chapters. We’d finish. We’d ship. We’d celebrate. Sometimes we celebrated, then shipped. But either way, we were done.
但后来事情真的开始发生了。通常发生的事情是人们抱怨我们提供的东西没有按照他们想要的方式工作。有时他们根本没有抱怨(我们后来发现这是没有人真正使用它的副作用)。然后我们会花很多时间假装我们成功了。对于你们中的一些人来说,这可能描述了你们公司今天的运作方式。老实说:这仍然是我经常重新投入工作的方式。不要告诉任何人。我应该是专家。
But then stuff actually started to happen. What usually happened was people complaining about what we’d delivered not working the way they wanted. Sometimes they didn’t complain at all (which we’d find out later was a side effect of no one really using it). We’d then spend a lot of time pretending we were successful. For some of you, that might describe the way your company works today. And I’ll be honest with you: it’s still the way I often fall back into working. Don’t tell anyone. I’m supposed to be an expert.
但是还有更好的选择。
But there are better alternatives.
多年前,一位潜在客户联系我,问我是否可以帮助它采用一种称为设计思维的过程。这个客户一直在使用典型的敏捷过程,并且做得非常好——“好”是因为它以可预测和高质量的方式交付。但它已经了解到,“你提供垃圾的速度越快,你得到的垃圾就越多。” 这听起来有点刺耳。换句话说,客户了解到,它构建的软件数量与它从中获得的结果和影响之间几乎没有关联。
Years ago, a potential client contacted me and asked me if I could help it adopt a process called design thinking. This client had been using a typical Agile process, and was doing it really well—“well” in that it was delivering predictably and with high quality. But it had learned that “the faster you deliver crap, the more crap you get.” That’s a little harsh sounding. To put it another way, the client had learned that there was little correlation between the quantity of software it built, and the outcome and impact it got from it.
当这个客户打电话时,我以我在用户体验设计和敏捷开发方面的专长而闻名。我心想:“我是设计师,我在思考,所以我一定是设计思维。” 但是我错了。客户不是这个意思。对我来说幸运的是,我没有大声说出我的想法。
When this client called, I was known for my specialty in user experience design and Agile development. I thought to myself: “I’m a designer, and I’m thinking, so I must be design thinking.” But I was wrong. That’s not what the client meant. Luckily for me, I didn’t say what I was thinking out loud.
设计思维是指一种工作方式,最初由一家名为 IDEO 的公司描述,后来由斯坦福大学的 d.school 描述和教授。如今,许多大学都在教授它,并在全球许多公司中使用它。
Design thinking refers to a way of working originally described by a company called IDEO, and then later described and taught by Stanford University’s d.school. These days, it’s taught in a number of universities and used in lots of companies worldwide.
设计思维过程有几个步骤,正如我解释的那样,这些步骤看起来显然是个好主意。但是,在实践中,我和大多数人倾向于做的恰恰相反。难怪事情经常变坏。
A design thinking process has several steps that, as I explain them, seem like obviously good ideas. But, in practice, what I and most people tend to do is the exact opposite. No wonder things go bad so often.
设计思维方法的第一步是同理心。这不叫研究,我通常希望在设计过程中进行研究。之所以称为同理心,是因为做这项工作的一个关键结果是了解成为您产品的用户的真实感受。为此,您需要前往用户所在的地方,与他们会面,观看他们的工作,最好是与他们一起工作。现在,当然,如果你为外科医生开发软件,没有人会期望你成为一名业余外科医生。但是尽你最大的努力去理解穿上他们的鞋子是什么感觉。重要的是要记住,在传统研究中,尤其是定量的不干涉的研究中,我们得到的是数据,而不是总是同理心。
The first step of a design thinking approach is empathize. It’s not called research, which I’d normally expect from a design process. It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product. To do this you need to go to where users are, meet them, watch them work, and ideally work alongside them. Now, of course, if you build software for surgeons, no one expects you to become an amateur surgeon. But do your best to understand what it’s like to walk in their shoes. It’s important to remember that out of traditional research, especially the quantitative hands-off stuff, we get data and not always empathy.
直接与客户和用户交谈。亲身体验您正在帮助他们应对的挑战。
Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.
下一步称为定义。从我们在 empathize 期间所做的工作中,我们学到了很多东西。但我们需要理解它——建立共同的理解。为此,我们将通过大量协作来讲述故事、分享和提炼我们所学到的知识。然后我们将选择要关注的特定人员和问题。
The next step is called define. From the work we do during empathize, we learn a lot. But we need to make sense of it—to build shared understanding. And we’ll do this using lots of collaboration to tell stories, share, and distill what we’ve learned. Then we’ll choose specific people and problems on which to focus.
在此处使用故事地图来绘制当今人们做事的方式。在其中包括您所见所闻的详细信息。关注用户的痛点,以及他们寻求的回报。使用简单的角色来构建一个综合您所学知识的优秀示例用户。选择要关注的具体问题。
Use story maps here to map the way people do things today. Include in them details of what you saw and learned. Focus on the pain points users have, and the rewards they seek. Use simple personas to build a good example user that synthesizes what you’ve learned. Choose specific problems to focus on.
真正专注于一个或几个问题。具体说明。
Really focus on one or a few problems. State them specifically.
下一步是构思。如果你在上一章中有密切关注,我们谈到了一种叫做设计工作室的简单实践。这是一个好的构思方法的例子。在常见的商业实践中,第一个想出可行想法的人就是赢家,想出很多可能的想法似乎是在浪费时间。如果您还记得您的第一个显而易见的解决方案是非常明显的,那么如果想出一个创新的解决方案真的很重要,那就想想过去吧。
The next step is ideation. If you were paying close attention in the last chapter, we talked about a simple practice called design studio. It’s an example of a good ideation approach. In common business practice where the first person to come up with a viable idea is the winner, it seems a waste of time to come up with lots of possible ideas. If you remember that your first obvious solutions are, well, obvious, then if really coming up with an innovative solution is important, think past that.
我喜欢使用故事地图作为构思的背景。使用显示痛苦、快乐和其他用户信息的地图,然后直接将想法集思广益。将解决方案的想法直接写在卡片或便签纸上,并将它们注入解决方案最相关的地图中。
I like using a story map as a backdrop for ideation. Use a map that shows pains, joys, and other information about users, and then brainstorm ideas directly into it. Write solution ideas directly on cards or stickies and inject them into the map where the solution is most relevant.
有意识地为客户和用户问题提出多种可能的解决方案。
Deliberately come up with multiple possible solutions to customer and user problems.
下一步是制作原型。现在,我们可能都知道原型是什么,但我们常常在急于构建可运行的产品时忽略了创建原型。很遗憾,真的。对简单纸质原型的少量投资有助于我们思考解决方案。他们帮助我们开始亲身体验。用纸或最简单的原型制作工具构建简单的原型,可以帮助我们过滤掉很多行不通的想法。开始模拟使用产品的实际行为有助于您继续构思——想出让解决方案变得更好的想法。
The next step is to prototype. Now, we likely all know what prototypes are, but we often neglect creating them in the rush to get working products built. It’s a pity, really. Small investments in simple paper prototypes help us think through our solution. They help us begin to experience it ourselves. Building simple prototypes out of paper, or the simplest of prototyping tools, helps us filter out a lot of ideas that just won’t work. Beginning to simulate the actual act of using a product helps you continue to ideate—to come up with ideas to make the solution even better.
构建简单的原型来探索您的最佳解决方案。将原型提升到一定程度的保真度,使用户和客户能够评估该解决方案是否真正解决了他们的问题。
Build simple prototypes to explore your best solutions. Advance prototypes to a level of fidelity that allows users and customers to evaluate whether the solution really solves their problem.
最后一步是测试。我并不是说检查是否有错误。我的意思是了解您的解决方案是否真的解决了某人的问题。您可能会感到惊讶,即使存在错误,它也能做到这一点。当你有一个你认为可以解决你选择关注的问题的原型时,把这个原型放在将使用你的产品的人面前。这不完全是“展示和讲述”。而且绝对卖不出去。潜在用户需要将原型视为他们可以用来解决他们的问题之一的东西。他们需要用它来完成真正的任务。你实际上可以通过伪造很多来实现这一点。
The last step is to test. By that I don’t mean check to see whether there are bugs. I mean learn whether your solution really does solve someone’s problem. You might be surprised that it could do that even with bugs. When you’ve got a prototype that you believe solves the problems you’ve chosen to focus on, put that prototype in front of people who’ll use your product. This isn’t exactly “show and tell.” And it’s definitely not selling. Potential users need to recognize the prototype as something they could use to solve one of their problems. They need to use it to accomplish a real task. You can actually accomplish this by faking a lot of it.
将您的解决方案呈现在购买或使用您产品的人面前。不要指望他们一开始就会成功。迭代并改进它们。
Get your solutions in front of the people who will buy or use your product. Don’t expect them to be a success at first. Iterate and improve them.
除了这五个步骤之外,设计思维的一部分是一种工作方式它强调小型、多学科的协作团队使用简单的模型、草图和低保真度的记录和交流方式快速合作。作为我在第 12 章中描述的发现团队和其他合作者,您应该认识到这一点。你应该认识到他们的工作方式是强调建立共同理解的方式。
In addition to those five steps, part of design thinking is a way of working that emphasizes small, multidisciplinary collaborative teams working together quickly using simple models, sketching, and low-fidelity ways of documenting and communicating. You should recognize that as the discovery team and other collaborators I described in Chapter 12. You should recognize their way of working as one that emphasizes building shared understanding.
使用设计思维的元素可以帮助我们真正理解我们正在解决的问题,所以我们不会解决我们想象的人们遇到的问题。在我们投入大量资金构建功能齐全的可扩展解决方案之前,对解决方案进行原型设计和测试有助于我们验证我们正在构建人们真正重视并可以使用的解决方案。
Using elements of design thinking helps us really understand the problems we’re solving, so we don’t solve problems we imagine people have. Prototyping and testing solutions before we invest big in building full-featured scalable solutions helps us validate that we’re building solutions people really value and can use.
但是单靠设计思维会导致一些问题。
But design thinking alone can lead to some problems.
设计过程已经存在了很长时间。设计思维作为一种通用的设计方法也有。一个好的设计过程可以比过去糟糕的日子有了巨大的进步。但是不要混淆过程和技巧。有一些可预测的设计流程失败方式。如果您看到一个好的设计过程花费太多时间并导致糟糕的结果,那么您可能会认为这些过程不起作用。这不是过程。
Design processes have been around a long time. Design thinking as a generalized approach to design has, too. And a design process done well can be a huge improvement over the bad old days. But don’t confuse process with skill. There are some predictable ways that design processes fail. If you’ve seen a good design process take way too much time and result in a bad outcome, then you might believe these sorts of processes don’t work. It’s not the process.
以下是一些扰乱设计过程的好方法:
Here are a few great ways to mess up a design process:
我知道我在这里有点刻薄。但我坚决主张使用设计流程。而且,奇怪的是,我发现我经常是抱怨他们的人。我还可以说,我对列出的几乎所有失败都感到内疚。但是,在过去的几年里,我发现了一种改进它们的典型设计方法的转折点。
I’m being a bit snarky here, I know. But I’m a strong advocate for using design processes. And, oddly, I find I’m often the one complaining about them. I can also say that I’ve been guilty of almost all the failures listed. But, over the past few years, I’ve found a twist on typical design approaches that improves them.
埃里克·里斯 (Eric Ries) 是一本名为《精益创业》(皇冠企业)的书的作者。埃里克在他的书中描述了他是如何陷入我之前描述为“糟糕的过去”的陷阱的。作为一家初创公司的首席技术官,他帮助他的公司打造了他们认为是成功的产品。只有他们的目标客户和用户不这么看。事实上,他们的回应大多是愉快的反馈、糟糕的反馈和彻底的冷漠。绝对不是他们想要的结果和影响。
Eric Ries is the author of a book called The Lean Startup (Crown Business). In his book Eric describes how he fell into the trap I described earlier as the “bad old days.” As the CTO of a startup, he helped his company build what they believed to be a successful product. Only their target customers and users didn’t see it that way. In fact, they mostly responded with a mixture of pleasant feedback, bad feedback, and outright apathy. Definitely not the outcome and impact they were looking for.
Eric 的公司顾问之一是 Steve Blank。史蒂夫写了一本书,叫做顿悟的四个步骤(K&S 牧场),他在书中断言,你需要开发的第一件事不是产品,而是客户。他描述了一个过程,用于逐步验证您是否找到了对解决方案感兴趣的客户,然后验证您想到的解决方案是他们将购买、使用并告诉其他人的解决方案。Blank 将此称为经过验证的学习过程。
One of Eric’s company advisors was Steve Blank. Steve had written a book called The Four Steps to Epiphany (K&S Ranch) in which he asserted that the first thing you need to develop isn’t a product, it’s customers. He described a process for progressively validating that you’ve found customers who are interested in a solution, and for then validating that the solutions you have in mind are the solutions they’ll buy, use, and tell others about. Blank referred to this as a validated learning process.
Eric Ries 对产品开发的最大贡献是将这种思维简化并“产品化”为这个简单的口头禅:构建-测量-学习。Eric 强调减少完成这个简单学习周期所需的时间。传统设计流程中最大的缺陷之一花很长时间学习和设计——时间太长以至于你对解决方案非常执着,然后却无法验证这些解决方案是否确实带来了你想要的结果。典型的设计过程可能需要数周或数月的时间来验证解决方案的想法,而精益启动过程通常只需要几天时间。
Eric Ries’s biggest contribution to product development is simplifying and “productizing” that thinking into this simple mantra: build-measure-learn. Eric emphasized reducing the time it takes to get through this simple learning cycle. One of the biggest flaws in traditional design processes is spending a very long time learning and designing—so long that you become very attached to the solutions, and then failing to validate that those solutions really do bring about the outcomes you intended. Where a typical design process may take weeks or months to validate a solution idea, a Lean Startup process usually takes just days.
在过去糟糕的日子里,我们会想出一个好主意,建造它,并希望最好的。
In the bad old days, we’d have come up with a big idea, built it, and hoped for the best.
如果我们试图通过严格的设计流程来打破这个陷阱,我们就会尽力搁置我们的伟大想法,然后深入研究以了解我们正在解决的问题。
If we were trying to break out of that trap using a rigorous design process, we’d have done our best to set aside our great ideas, and then dig deep into research to understand the problems we’re solving.
这是我建议我们今天做事的方式,使用精益创业思维。
Here’s how I recommend we do things today, using Lean Startup thinking.
是的,猜测。
Yes, guessing.
在过去糟糕的日子里,你会猜到并假装你不是。在设计过程中,您不允许自己去猜测。反正你会的。但你会假装你不是。所以别假装了。
In the bad old days, you’d have guessed and pretended you weren’t. In a design process, you’d not have allowed yourself to guess. You would have anyway. But you’d have pretended you weren’t. So just stop pretending.
其实不只是猜测。激情、经验和洞察力的结合——以及相当多的猜测——使事情顺利进行。我通常通过绘制简单的原型来假设和猜测我的用户是谁。我将通过构建简单的“现在”故事地图来描述我认为它们今天的工作方式。我将与其他对用户和客户有第一手经验的人合作来完成这项工作。而且,在某些情况下,我会直接让客户和用户参与进来。所以,其实我们团队的很多猜测根本就不是猜测。但这也不完全是我们过去所做的研究。我们会花几个小时到几天时间做这样的事情——而不是几周或几个月。
It’s actually not just guessing. It’s a mixture of passion, experience, and insight—along with a fair dose of guessing—that gets the ball rolling. I take my assumptions and guesses about who my users are, usually by sketching simple prototypes. I’ll describe how I think they work today by building simple “now” story maps. I’ll do this collaboratively with other people who have firsthand experience with users and customers. And, in some situations I’ll do this involving customers and users directly. So, in fact, many of our team’s guesses aren’t guesses at all. But it’s not exactly research like we used to do, either. We’ll spend hours to a couple of days doing stuff like this—never weeks or months.
在我们对谁将使用该软件达成共识并关注我们正在解决的问题之后,我们就会猜测解决方案。我们将使用设计思维原则——有意识地提出并考虑多种解决方案。但我们会尝试快速汇集我们认为最好的解决方案。有时我们无法决定一个单一的解决方案,而是选择几个。我们不会为此过度紧张,因为我们知道无论如何我们都可能错了。
After we’ve all got shared understanding about who will use the software and some focus in the problems we’re solving, we then guess at the solution. We’ll use principles of design thinking—deliberately coming up with and considering multiple solutions. But we’ll try to converge quickly on what we think our best solution is. Sometimes we’ll fail to decide on a single solution, and pick a couple. We don’t wring our hands about this too much, because we know we’re probably wrong anyway.
由于我们今天可能已经猜测了很多关于我们的用户和他们面临的挑战,所以我们将命名这些猜测。具体来说,我们将共同努力,将我们认为是真实的事情写成项目符号列表,但如果我们发现它们不是,那么我们将需要重新考虑一切。
Since we may have guessed a lot about our users and their challenges today, we’ll name those guesses. Specifically, we’ll work together to write a bulleted list of the things we believe are true, but if we find they aren’t, then we’ll need to rethink everything.
我们将对我们的解决方案做同样的事情。我们会考虑我们相信人们会如何回应它以及他们会如何使用它。我们将在脑海中形成一个关于我们认为他们将如何处理我们的解决方案的假设。我们还将讨论技术风险——会威胁到我们解决方案可行性的事情。
We’ll do the same with our solution. We’ll think about how we believe people will respond to it and how they’d use it. We’ll form a hypothesis in our minds about how we think they’ll behave with our solution. We’ll also discuss technical risks—things that would threaten the feasibility of our solution.
鉴于我们的客户、用户和我们的解决方案的风险和假设列表,我们将确定我们认为最大的风险是什么。
Given a list of risks and assumptions about our customers, our users, and our solution, we’ll identify what we think the few biggest risks are.
Here’s where things get really different.
在过去糟糕的日子里,我们会计划并构建一个完整的产品。在设计过程中,我们会对整个产品或大部分产品进行原型制作。但是使用精益创业方法,我们的目标是尽快学习一些东西,我们将尽最大努力制作尽可能小的原型。在很多情况下,根本就很难将其称为原型。
In the bad old days, we’d have planned and built a whole product. In a design process, we’d have prototyped a whole product, or most of it anyway. But using a Lean Startup approach, where our goal is to learn something as quickly as possible, we’ll do our best to make the smallest prototype possible. In lots of cases, it’ll be hard to call it a prototype at all.
这是我在一个名为 ITHAKA 的非营利组织的朋友的例子。他们生产一种名为 JSTOR 的产品。如果您在过去十年被美国大学录取,您可能会在大学图书馆中使用 JSTOR 来查找您必须撰写的论文的文章和书籍。
Here’s an example from my friends at a nonprofit organization called ITHAKA. They make a product called JSTOR. If you’ve been enrolled in a US college in the last decade, you likely used JSTOR in your college library to find articles and books for a paper you had to write.
使用该产品的学生希望在任何地方都能轻松使用它——在咖啡店、家里或旅行时。但是从校外进入 JSTOR 对学生来说可能是一个挑战。它要求他们为他们的大学设置一个用户名和密码,这样当他们坐在咖啡店里时,他们就可以登录并访问他们大学获得许可的所有资源。JSTOR 团队已经有了解决方案,但使用起来有点棘手。他们想测试一种新的做事方式。
The students using the product wanted to easily use it from anywhere—at coffee shops, or at home, or when they traveled. But getting to JSTOR from outside the college could be a challenge for students. It required them to set up a username and password with their college so when they were sitting in a coffee shop, they could log in and get access to all the resources their university had licensed. The JSTOR team already had a solution, but it was a bit tricky to use. They wanted to test a new way of doing things.
他们对这些学生有以下假设:
They had these assumptions about those students:
他们对解决方案有以下假设:
They had these assumptions about their solution:
为了检验他们的假设,JSTOR 团队不需要构建软件——现在还不需要。他们需要与学生具体讨论他们在进行研究时所处的位置,尤其是在他们使用 JSTOR 时。该团队需要确认学生面临他们想象的挑战,并且鉴于此,学生认为 JSTOR 的解决方案理念可以解决这些挑战。
To test their assumptions, the JSTOR team didn’t need to build software—not yet. They needed to talk to students specifically about where they were when they were doing research, especially when they were using JSTOR. The team needed to confirm that students had the challenges that they imagined, and, given that, that students thought JSTOR’s solution idea would address those challenges.
该团队计划与很多学生交谈。而且,为了更容易和更一致地向学生描述问题和他们的解决方案,他们创建了一个简单的设计漫画。如果您还没有看过,设计漫画正是它听起来的样子。它看起来像漫画书中的几页。但是,它不是展示超级英雄与超级恶棍的战斗,而是展示真实的人用你的解决方案想法解决一个真正的问题。
The team planned on talking to lots of students. And, to make it easier and more consistent to describe the problem and their solution to students, they created a simple design comic. If you haven’t seen one, a design comic is exactly what it sounds like. It looks like a few pages from a comic book. But, instead of showing superheroes battling supervillains, it shows real people solving a real problem with your solution idea.
以下是 JSTOR 设计漫画中的几页(由 ITHAKA 提供,© 2014 ITHAKA,保留所有权利):
Here are a few pages from JSTOR’s design comic (reproduced courtesy of ITHAKA, © 2014 ITHAKA, all rights reserved):
团队设计的测试要求他们花一点时间采访学生以了解他们今天面临的挑战。然后,他们会与学生一起回顾这个场景,看看他们的解决方案是否能解决学生面临的挑战。他们没有构建完整的原型。他们确实担心他们的解决方案是否真的有用,而他们无法从漫画书中学到这一点。他们还有一些技术问题需要编写一些原型代码进行测试。但如果学生没有问题,并且对他们的想法反应不佳,那么这一切都无关紧要。
The test the team designed required that they spend a little time interviewing students to learn about their challenges today. And then, they’d review the scenario with the students to see if their solution looked like it would address the students’ challenges. They didn’t build a full prototype. They did have concerns that their solution would be really usable, and they couldn’t learn that from a comic book. They also had a few technical concerns that would require writing some prototype code to test. But none of that mattered if students didn’t have the problem, and didn’t respond well to their idea.
最小可行的测试解决方案就是 Lean Startup 所说的最小可行产品。是的,Eric Ries 知道这不是一个完整的产品。但是,当您的目标是学习时,它是您可以构建用于学习的最小产品。
That smallest possible solution to test is what Lean Startup refers to as a minimum viable product. Yes, Eric Ries knows it’s not a whole product. But, when your goal is learning, it is the smallest product you could build to learn.
将测试放在客户和用户面前。在早期工作中,这通常意味着安排面试和与人相处。如果您正在创建消费者解决方案,您可以进行客户拦截,这是一种技术上的说法,就是去你的客户和用户所在的地方,阻止他们,并与他们交谈。当我一起工作的人去购物中心、咖啡店和旅游景点时,我已经标记了他们。
Put the test in front of customers and users. In early work this usually means schedule interviews and spend time with people. If you’re creating a consumer solution, you can do customer intercepts, which is a technical way of saying go to where your customers and users are, stop them, and talk to them. I’ve tagged along with people I work with as they go to shopping malls, coffee shops, and tourist attractions.
JSTOR 招募了学生和研究生,并先与他们交谈 30-60 分钟,以采访和了解他们今天的工作方式,以便团队可以确认他们对正在解决的问题的假设。然后他们引导学生浏览设计漫画,以获得他们对解决方案想法的回应。
JSTOR recruited students and grad students and spent 30–60 minutes talking with them first to interview and learn how they did things today so the team could confirm their assumptions about the problems they were solving. Then they stepped students through the design comic to get their response to the solution idea.
运行几次测试后,您将开始获得可预测的结果。如果你完全错了,你通常会很快学会。收回你学到的东西。将这些事实回溯到您认为您对用户的了解以及他们今天的工作方式。用它来重新考虑你的解决方案。然后,重新考虑您对用户和解决方案的假设。然后设计你的下一个测试。
After running your test a few times, you’ll begin to get predictable results. If you’re dead wrong, you’ll often learn that pretty quickly. Take back what you’ve learned. Roll those facts back into what you thought you knew about your users, and the way they work today. Use that to rethink your solution. Then, rethink your assumptions about users and solutions. Then design your next test.
在 JSTOR 人员进行测试后,他们了解到一些学生并没有他们认为的问题。通常这会是令人失望的消息,因为我们都讨厌犯错。但是,在精益创业方法中,这是个好消息。这非常好,因为他们在经过几天的思考和工作后发现自己错了,而不是在团队构建软件几周后才发现。
After the JSTOR folks ran their tests, they learned that some students didn’t have the problems they thought they did. Normally this would be disappointing news, because we all hate being wrong. But, in a Lean Startup approach, this is excellent news. It’s excellent because they found they were wrong after a couple of days of thinking and working, as opposed to finding out after weeks of a team building software.
如果你使用这种方法,你最大的挑战将是学会庆祝你正在学习的东西,而不是担心会犯错。
If you’re using this sort of approach, your biggest challenge will be to learn to celebrate what you’re learning as opposed to worrying about being wrong.
在精益创业方法中,不学习通常是最大的失败。
In a Lean Startup approach, failing to learn is frequently the biggest failure.
在精益创业方法中,构建意味着构建尽可能小的实验你可以。度量可以是从工作软件中收集的分析、从访谈和/或面对面的原型测试中直接观察到的。学习是我们对信息所做的事情。这是对我们的假设的重新思考,并改革我们认为是未来最好的解决方案。
In a Lean Startup approach, build means build the smallest possible experiment you can. Measure may be analytics gathered from working software, direct observations from interviews and face-to-face testing of prototypes, or both. Learning is what we do with the information. It’s the rethinking of our assumptions and reforming what we believe to be a best solution going forward.
您可能会问,“这一切中的故事和故事地图在哪里?” 你问的是对的。
You might be asking, “Where are the stories and story maps in all this?” And you’d be right to ask.
在经过验证的学习方法中,您将不断讲故事关于您的用户是谁,他们在做什么以及为什么。您将使用故事地图来讲述有关人们当今如何工作以及您想象他们将如何使用您的解决方案的更大故事。当需要构建原型时,您将使用故事和故事对话来具体商定您正在构建的原型应该是什么样子,以及您将检查哪些内容以确认原型已完成。在您了解故事是一种工作方式之后,您会发现很难判断您何时使用或不使用它们。
Throughout a validated learning approach, you’ll be constantly telling stories about who your users are, what they’re doing, and why. You’ll use story maps to tell bigger stories about how people work today, and how you imagine they’ll use your solution. When it comes time to build prototypes, you’ll use stories and story conversations to agree specifically on what the prototype you’re building should look like, and what you’ll check to confirm the prototype is done. After you understand that stories are a way of working, you’ll find it’s difficult to tell when you are or aren’t using them.
不过,我们在发现过程中使用故事的方式存在很大差异。通常,当我们使用它们时,我们会与开发人员、测试人员和许多其他人讨论我们打算构建并投入生产的软件。我们将非常努力地工作以确保我们达成共识。我们将详细介绍如何构建软件,这样我们就可以学到足够多的知识来预测地估计需要多长时间。通常我们会讨论一些故事,这样我们就可以在两周的冲刺或迭代中完成多少达成一致。但是我们在发现过程中的工作方式更快。我们希望在数小时而不是数天内构建简单的原型。即使是我们希望使用代码和实时数据构建的原型也需要几天而不是几周的时间。我们正在建设中学习,我们预计我们的大部分想法都会失败,或者至少,需要一些调整才能成功。所以我们专注于快速合作,快速达成一致,并尽量减少手续。
There is one big difference in the way we use stories during discovery, though. Usually when we’re using them, we’re talking with developers, testers, and lots of others about the software we intend to build and put into production. We’ll work pretty hard to make sure we’ve got shared understanding. We’ll get into a lot of details about how we’ll build the software so we can learn enough to predictably estimate how long it’ll take. Usually we’ll talk about a number of stories so we can agree on how much we can get done in a two-week sprint or iteration. But the way we’re working during discovery is faster. We hope to build simple prototypes in hours, not days. Even the prototypes we build using code and live data we hope will take days, not weeks. We’re building to learn, and we expect most of our ideas to fail, or at minimum, need some adjustment to be successful. So we focus on working together quickly, agreeing quickly, and minimizing the formality.
在发现和验证学习期间,您可能会不断讲故事、分解想法并将其分解为可构建的小块,并就构建的确切内容达成一致。你会做得太快以至于你不会清楚你正在使用故事。但你是。
During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces, and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.
[ 14 ] Jim Johnson,Standish Group 主席,“ROI,这是你的工作”(主题演讲),第三届极限编程国际会议,意大利阿尔盖罗,2002 年 5 月 26 日至 29 日。
[14] Jim Johnson, Chairman of the Standish Group, “ROI, It’s Your Job” (keynote), Third International Conference on Extreme Programming, Alghero, Italy, May 26–29, 2002.
[ 15 ] Deborah Gage,“风险投资的秘密:4 家初创公司中有 3 家失败”,《华尔街日报》,2012 年 9 月 20 日, http: //on.wsj.com/UtgMZl。
[15] Deborah Gage, “The Venture Capital Secret: 3 Out of 4 Start-Ups Fail,” Wall Street Journal, September 20, 2012, http://on.wsj.com/UtgMZl.
那么现在怎么办?如果故事是为了计划和促进讨论以构建软件,那么我们所做的一切似乎都是在谈论很多。
So, now what? If stories are for planning and facilitating discussions in order to build software, all we seem to be doing is lots of talking.
你的第一组对话帮助你理解了一个机会。你谈到了谁会使用你的产品,并想象他们将如何使用它来完成对他们有价值的事情。你们的谈话深入到足以将大机会分解成足够小的部分,这样你就可以分辨出哪些部分对于下一个产品发布很重要,哪些部分无关紧要。您将描述下一个可行版本的故事收集到版本积压中。
Your first bunch of conversations helped you make sense of an opportunity. You talked about who’d be using your product, and imagined how they’d use it to accomplish something valuable to them. Your conversations went deep enough to break the big opportunity into parts that were small enough that you could tell which parts were important to be in a next product release, and which didn’t matter so much. You collected the stories that described that next viable release into a release backlog.
如果你很聪明,我知道你很聪明,那么你接下来的谈话会更深入地讨论软件的外观、它的行为方式,以及它如何融入你现有的产品和软件架构。你在密切关注有风险的事情的情况下进行了这些对话。您将故事分割成您可以尽早构建的部分,这将帮助您更快地了解更多。因为你很聪明,你将你的发布积压分成故事,以便在早期学习,在中间建立,然后再完善。
If you’re clever, and I know you are, your next conversations went deeper into what the software might look like, how it would behave, and how it might knit into your existing product and software architecture. You had these conversations with a close eye on the risky stuff. You sliced up the stories into the parts that you could build early that would help you learn more, faster. And because you’re clever, you segmented your release backlog into stories to take on early to learn, in the middle to build up, and later to refine.
但现在它变得真实了。是时候进行我们最好的最后一次对话了。
But now it gets real. It’s time to have our best last conversations.
我们想着手建造这些东西,我们知道如果我们能够简明扼要地描述我们想要构建的内容,那么构建我们讲故事所描述的软件将会顺利且可预测地进行。但是,在所有这些对话之后,我们留下的故事感觉有点粗糙。我们可能还没有足够详细地讨论它们中的任何一个,以准确了解它们是什么,它们不是什么,并真正预测它们将花费多长时间来构建。但我们有一台神奇的机器可以解决这一切。
We’d like to get to work building these things, and we know that building the software that our storytelling describes will go smoothly and predictably if we can concisely describe exactly what we’d like to build. But, after all these conversations, the stories we’re left with feel a little rough around the edges. We likely haven’t talked about any of them in enough detail to understand precisely what they are and what they aren’t, and really predict how long they’ll take to build. But we’ve got a magical machine that’ll fix all this.
我想让你想象一个设计精美的小机器。我们会将发布积压的参差不齐、粗略的故事放入左侧的大漏斗中。然后,在机器内部,我们会听到轻微的摩擦声和咔嗒声。但随后从右侧的小喷口中流出小而光滑的小金块。这些小块是团队成员可以挑选并用于可预测地构建高质量软件的东西。
I want you to picture an elegantly designed little machine. We’ll drop jagged, rough stories from our release backlog into a big funnel on the left side. Then, inside the machine, we’ll hear a little grinding and clattering. But then out of a little spout on the right side comes small, polished little nuggets. These little nuggets are the things that team members can pick up and use to predictably build high-quality software.
这台机器从外面看起来很神奇。但是,在内部,您和您的团队正在进行一些严肃的切石和抛光讨论。隐藏在这台机器内部的特殊秘密机构是一个故事工作室。
This machine looks magic from the outside. But, on the inside, you and your team are having some serious rock-cutting and polishing discussions. The special, secret mechanism hidden inside this machine is a story workshop.
您可能还记得第 11 章,故事研讨会是小型的、富有成效的对话,合适的人在一起最后一次讲故事,并在此过程中做出关于他们将选择构建什么的所有艰难决定。这些是导致确认的深层故事对话。最后,我们将进入卡片-对话-确认流程中的第三个C。正是这种C帮助我们真正切割并为这些岩石添加抛光剂。
As you might recall from Chapter 11, story workshops are small, productive conversations where the right people work together to tell the stories one last time, and in the process make all the tough decisions about exactly what they’ll choose to build. These are the deep story conversations that result in confirmation. Finally, we’re getting to that third C in the card-conversation-confirmation flow. And it’s this C that helps us really cut and add the polish to these rocks.
您需要一个小组,其中包括一名开发人员、一名测试人员以及了解用户和 UI 外观和行为的人员——某些组织中的 UI 设计师或业务分析师。当小组人数足够少,可以在白板前有效地协同工作时,这种方法效果最好。一般是三五个人。
You’ll need a small group that includes a developer, a tester, and people who understand users and how the UI will look and behave—UI designers or business analysts in some organizations. This goes best when the group is small enough to work together effectively in front of a whiteboard. That’s usually three to five people.
这是一个研讨会,而不是在会议中。会议这个词已经成为非生产性协作的委婉说法。故事研讨会需要充满大量富有成效的讨论、挥手、白板绘图和素描。我们需要共同努力来决定我们要建造什么。我们必须以坚定的共同理解结束这次对话,我们需要空间来进行那些富有成效的文字和图片对话。
This is a workshop, not in a meeting. Meeting is the word that has become a euphemism for unproductive collaboration. A story workshop needs to be filled with lots of productive discussion, hand waving, whiteboard drawing, and sketching. We’ll need to work together to decide exactly what we’ll build. We’ve got to come out of this conversation with solid shared understanding, and we’ll need space to have those productive words-and-pictures conversations.
在之前的所有这些对话中,我们讨论了细节,但希望我们能够克制到足够深入以做出当时需要的决定。我们现在所做的决定集中于回答这个问题:我们到底要建造什么?
In all those conversations prior to now, we talked through details, but hopefully we had the restraint to go just deep enough to make the decisions we needed to at the time. The decisions we’re making now focus on answering the question: exactly what will we build?
正是在这次谈话中,你会发现你的故事太大了。我的意思是它比我们希望看到的理想规模要大——几天或更短的时间来开发。好的,它并不总是太大。但是,如果您只是假设它会是,那么当它不是时您会感到惊喜。令人高兴的是,房间里有合适的人来帮助您将这个故事分解成更小的故事,这些故事可以在团队正在共同构建的不断增长的产品中交付、测试和演示。
It’s during this conversation that you’ll find out your story is too big. By that I mean it’s bigger than the ideal size we like to see going into development—a couple of days or less to build. OK, it’s not always too big. But, if you just assume it will be, then you’ll be pleasantly surprised when it’s not. Happily, you have exactly the right people in the room to help you break down this story into smaller stories that can be delivered, tested, and demonstrated in the growing product the team is working together to build.
一些敏捷实践者在迭代计划或冲刺计划等计划会议期间完成这些关键故事对话。如果您正在与高效协作的团队合作,并且在深入了解他们的产品的情况下参与讨论,那么这会非常有效。对于我合作多年的团队,这就是我们做事的方式。
Some Agile practitioners accomplish these critical story conversations during planning sessions like iteration planning or sprint planning. That works pretty well if you’re working with teams that work effectively together and come into the discussion with a good understanding of their product. For teams I worked with for years, that’s the way we did things.
但我从敏捷团队那里听到的最大抱怨之一是,这些计划会议通常是漫长而痛苦的事情。在某些时候,每个人都同意构建什么,即使他们没有共同的理解,只是为了让这个痛苦的会议停止。
But one of the biggest complaints I hear from Agile teams is that these planning meetings are often long, torturous affairs. At some point everyone agrees on what to build, even if they don’t have shared understanding, just to make this torturous meeting stop.
痛苦的冲刺计划会议已经成为一种常见的功能障碍,以至于许多团队明智地选择在会议前几天进行这些故事讨论。他们通常将这些安排在他们的日历中,作为预先计划会议、积压工作梳理或积压工作改进会议。但是,经常发生的情况是,他们只是将他们在计划会议期间所厌恶的折磨转移到了另一天。雪上加霜的是,团队成员被要求从他们目前的生产性工作中休息一下,坐下来忍受这种折磨。难怪他们对此并不兴奋。
The torturous sprint planning meeting has become such a common dysfunction that many teams sensibly choose to have these story discussions in the days preceding the meeting. They often have these scheduled in their calendars as pre-planning meetings, backlog grooming, or backlog refinement meetings. But, too often, what happens is they’ve simply moved the same torture they hated during the planning meeting to a different day. To add insult to injury, team members are asked to take a break from their current productive work to sit through this torture. No wonder they’re not excited about it.
问题不在于故事对话很难。好吧,实际上他们有时会很难。但是,所有的谈话都因为试图包括太多人而变得更加艰难。如果其中许多人没有兴趣或没有动力参与,那你就完蛋了。你知道我说的那些人——那些假装我们看不到他们在桌子底下玩智能手机的人。
The problem isn’t that story conversations are hard. Well, actually they can be pretty hard at times. But all conversations are made tougher by trying to include too many people. If many of those people aren’t interested or motivated to participate, you’re doomed. You know the people I’m talking about—the ones pretending we can’t see them playing with their smartphones under the table.
允许团队成员选择加入这些对话。如果以后他们抱怨所做的决定,请确保下次邀请他们到场。
Allow team members to opt in to these conversations. If later they complain about the decisions made, make sure you invite them to be there next time.
如果每个人都想参与,请尝试使用像下面边栏中描述的那样的鱼缸协作模式。这样,感兴趣的人就可以顺路过来,如果他们愿意,就可以参加,如果他们发现他们没有错过任何令人兴奋的事情,就可以离开。
If everyone wants to participate, try using a fishbowl collaboration pattern like the one described in the following sidebar. This way, interested people can drop by, participate if they want, and leave if they find they’re not missing anything exciting.
还记得第 8 章中关于蛋糕和纸杯蛋糕的讨论吗?现在是时候将这些蛋糕分解成最小的纸杯蛋糕了。现在——当我们拥有开发人员、测试人员和其他真正能够构建软件的人时——我们才能真正想象我们如何分解这个故事。
Remember the cake and cupcakes discussion from Chapter 8? Now’s the time to break down those cakes to the smallest cupcakes you can. It’s now—when we’ve got developers, testers, and others who can really build the software—that we can really imagine how we could break down the story.
请记住,软件是“软的”。好吧,它不像海绵或纸杯蛋糕那样柔软。理想情况下,它更像是一个相当大的文档或一本书。如果你正在写一本书,就像我现在正在尽我最大的努力那样,你就不会试图一次完成所有的事情。你可能会坐下来一次写一章。事实上,我会一次写一章,彼得,我称职的、支持我的编辑,会审阅我所写的内容,并提出更正和建议。
Remember that software is “soft.” Well, it’s not soft like a sponge or a cupcake. Ideally, it’s more like a rather large document or a book. If you were writing a book, like I’m doing my best to do right now, you wouldn’t try to do it all at one time. You might sit down and write a chapter at a time. In fact I’ll write a chapter at a time, and Peter, my competent, supportive editor, will review what I’ve written and make corrections and suggestions.
但是这一章还没有“完成”。离得很远。
But then the chapter’s not “done.” Far from it.
我需要回过头来找出应该有插图的地方。我需要弄清楚是否应该添加脚注、参考文献、术语表或索引项。然后出版商的其他编辑将回顾每一章,进行最后的改进。我很自然地把工作分开来迭代完成,这样我就可以更快地看到整本书的成型。
I’ll need to go back through and figure out where there should be illustrations. I’ll need to figure out if I should add footnotes, references, glossary terms, or index items. Then other editors from the publisher will go back through each chapter, making final refinements. I’ve naturally split up the work to do it iteratively so that I can see the whole book take shape sooner.
您正在阅读“优化、定义和构建”一章。如果您现在正在阅读它,则希望它已经完全成熟。如果我要考虑我的最终验收标准,我会说它应该是:
You’re reading the “Refine, Define, and Build” chapter. And if you’re reading it now, it’s hopefully fully baked. If I were to think about my final acceptance criteria, I’d say it should be:
废话,这是很多工作。即使我现在将这些内容输入初稿,我也意识到我还有很多工作要做。但我不想在继续下一章之前完成所有这些,因为我想看看整本书是如何联系在一起的。因此,我将把它分解成“纸杯蛋糕”——还没有准备好发货的小而完整的部分,但这增强了我的信心,让我相信我在阅读本书时走在正确的轨道上。
Crap, that’s a lot of work. Even as I type those things into the first draft now, I realize I’ve got lots of work to do. But I don’t want to do all of it before moving on to the next chapter, because I’d like to see how the whole book is hanging together. So I’ll break it into “cupcakes”—small, complete parts that aren’t ready to ship, but that boost my confidence that I’m on the right track as I move through this book.
我会把我的工作分解成这样的故事:
I’d break down my work into stories like this:
我可以讲故事的每一件事都描述了它的样子,并思考了我(在 Peter 的编辑协助下)必须完成的步骤,以完成这些较小的版本和对章节的改进。您可以看到,随着每件事的完成,本章会逐渐变得更加完善,并且更接近于发布。理论上,列表中的第一个故事完成后,您可以看到并消费一些东西。但我不会那样对你。它不会很漂亮,你的反应也不会很好。
Each one of those things I can tell a story about describes what it looks like, and thinks through the steps I (with Peter’s editing assistance) must accomplish to finish each of these smaller versions and improvements to the chapter. And you can see that as each thing is completed, the chapter gets progressively more refined and closer to releasable. In theory, there’s something you could see and consume after the first story in the list is done. But I wouldn’t do that to you. It wouldn’t be pretty, and your reactions wouldn’t be good.
最后,由于我知道您在游戏中处于领先地位,您可能已经注意到较小的纸杯蛋糕大小的故事列表看起来很像本章的验收标准。这就是这里的魔力。正是对验收标准的讨论揭示了我们如何将工作分解成更小的部分,我们可以在整个过程中创建和检查。
Finally, since I know you’re on top of your game, you may have noticed that the list of smaller, cupcake-sized stories looks a lot like the acceptance criteria for the chapter. That’s the magic here. It’s the discussion of the acceptance criteria that reveals how we could break down the work into smaller parts we could create and inspect along the way.
在整个过程中检查您的工作很重要,这样您就可以对其进行评估并进行课程更正。您应该已经看到我最初在这里写的那个非常愚蠢的例子。但是你永远不会看到它,因为我写了它,检查了它,然后删除了它。
It’s important to inspect your work along the way so you can evaluate it and make course corrections. You should have seen the really stupid example I’d originally written here. But you’ll never see it because I wrote it, inspected it, and then removed it.
在传统的软件过程中,这种“检查和删除”的东西被称为不良需求。但是,当您戴上敏捷帽子时,这只是学习和迭代改进。
In a traditional software process, that “inspecting and removing” stuff would be called bad requirements. But, when you’ve got your Agile hat on, it’s just learning and iterative improvement.
当你真的有很好的故事讨论时,我知道你会的,在故事研讨会结束时,您应该拥有由大量额外文档和模型支持的大小合适的故事,以及描述您将如何检查该故事以确认它已完成的验收标准。有时需要一些外部研究、分析和设计工作支持的几个研讨会才能达成一致,但这没关系。切割和抛光需要时间,也需要更多的耐心。
When you’re really having good story discussions, and I know you will, at the end of a story workshop you should have right-sized stories supported by lots of extra documentation and models, and by acceptance criteria that describe how you’ll check this story to confirm it’s done. Sometimes it’ll take a couple of workshops supported by a little outside research, analysis, and design work to arrive at agreement, but that’s OK. Cutting and polishing takes time, and a bit more patience.
使用地图与您的交付团队建立共识。我经常听到在敏捷过程中工作的团队成员说他们有多喜欢协作,以及他们觉得有多高效,因为他们每隔一两周就会看到并演示工作软件。但随后他们接着说,“我觉得我失去了全局。我所看到的只是我们制造的产品的这些小部分。” 使用地图让团队了解您正在处理的整个产品或功能。如果他们了解这些决策适合的背景,他们将做出更好的战术设计和开发决策。
Use a map to build shared understanding with your delivery team. I often hear from team members working in an Agile process how much they like collaborating, and how productive they feel because every week or two they see and demonstrate working software. But then they follow that up with statements like, “I feel like I’ve lost the big picture. All I see are these little parts of the product we build.” Use a map to give the team the visibility of the whole product or feature you’re working on. They’ll make better tactical design and development decisions if they understand the context those decisions fit into.
当您开始构建产品版本时,地图会成为一个很好的可视化仪表板,以显示您已构建和未构建的内容。
As you begin to build your product release, the map makes a good visual dashboard to show what you have and haven’t built.
一些团队在开发完成时从地图主体中删除详细故事。这样,当他们查看地图时,他们所看到的就是剩下要建造的东西。
Some teams remove detailed stories from the body of the map as they bring them into development to complete. That way, when they look at the map, all they see is what’s left to build.
其他团队喜欢将地图留在原地并使用钢笔或彩色贴纸标记他们完成的故事。当他们退后一步查看地图时,他们会看到已完成的事情和剩下要做的事情的可视化。
Other teams like leaving the map in place and using pens or colored stickers to mark the stories they’ve completed. When they step back and look at the map, they see a visualization of what’s done, and what’s left to do.
使用地图确定下一个要建造的故事。每周,产品负责人都需要评估正在进行的开发工作的进展情况,并决定下一步要重点关注什么。当地图可视化进度时,扫描它以查找需要更多关注的区域会更容易一些。这有点像画家。如果你能退后一步,仔细观察整幅画,就更容易找出下一步从哪里开始工作。
Use the map to identify the next stories to build. Every week, product owners will need-assess the progress of ongoing development work, and make decisions about what’s important to focus on next. When the map visualizes progress, then it’s a bit easier to scan it to look for areas that need more focus. It’s sort of like being a painter. If you can step back and take in the entire painting, it’s easer to figure out where to start working next.
在每个开发周期中,您将在地图中确定接下来应该处理的故事。您将把这些故事带入您在故事研讨会期间进行的最后一次最佳对话中。
Each development cycle, you’ll identify stories in the map you should work on next. You’ll carry those stories into those last best conversations you’ll have during story workshops.
在研讨会期间构建的一个简单的可视化是一张简单的地图。您可能只映射了用户使用您正在讨论的功能所采取的三四个步骤。但是能够指向墙上显示流程的便利贴有助于讨论更快地进行。当您开始讨论验收标准时,将它们写在便利贴上并将它们添加到这张迷你地图中。最后,您将拥有一个简单的可视化效果来支持您在本次研讨会中进行的对话。
An easy visualization to build during that workshop is a simple map. You might be mapping only the three or four steps the user takes using a feature you’re discussing. But being able to point to sticky notes on a wall that show the flow helps the discussion move faster. As you begin to discuss acceptance criteria, write them on sticky notes and add them into this mini-map. In the end, you’ll have a simple visualization that supports the conversation you had in this workshop.
如果您到了一定年龄,您可能会深情地回忆起玩过一款名为Asteroids的早期视频游戏。在这里陪我一会儿。我保证这是相关的。
If you’re of a certain age, you may fondly recall playing an early video game called Asteroids. Stick with me here for a moment. I promise this is relevant.
在小行星游戏中,您的代表是一艘漂浮在外太空深处的小船。但是你被困在一片巨大的小行星领域,你需要开枪逃生!如果你射击一颗大的小行星,它会爆炸成几颗较小的小行星。而且,让事情变得更复杂的是,这些较小的小行星移动得更快,而且方向不同——这让你更难避免被击中。如果你射击其中一颗较小的小行星,它会分裂成更小的小行星,这些小行星向不同方向移动得更快。很快,屏幕上就充满了各种大小的小行星,这些小行星向各个可能的方向飞来飞去。令人高兴的是,当你射击最小的小行星时,它们会完全爆炸并帮助清理这个烂摊子。
In the game Asteroids, you’re represented by a little ship floating deep in outer space. But you’re stranded in a field of huge asteroids, and you need to shoot your way out to survive! If you shoot a big asteroid, it explodes into a few smaller asteroids. And, to make things more complicated, these smaller asteroids move faster, and in different directions—which makes it harder for you to keep from getting hit. If you shoot one of those smaller asteroids, it’ll break into even smaller asteroids that move even faster in different directions. Pretty soon, the screen is full of asteroids of all different sizes flying in every possible direction. Happily, when you shoot the tiniest asteroids, they blow up completely and help clear away this mess.
一个非常糟糕的小行星策略是射击所有的大石头并将它们分解成小石头。屏幕上到处都是许多飞来飞去的小石头,你会死得又快又痛苦。
A really bad asteroid strategy is to shoot all the big rocks and break them down into small rocks. The screen fills with lots of small rocks flying every which way, and you’ll die a quick and painful death.
一个非常糟糕的产品积压管理策略是分解所有大故事,使它们足够小以适应下一个开发周期。你的积压工作将充满大量飞来飞去的小故事,你会死的。好吧,你实际上不会死,但你会被许多不必要的复杂性活埋。你和其他人都会抱怨在所有这些微小的细节中失去了大局。
A really bad product backlog management strategy is to break down all the big stories so they’re small enough to fit into the next development cycle. Your backlog will fill with lots of small stories flying every which way, and you’ll die. Well, you won’t actually die, but you’ll be buried alive in a lot of needless complexity. You and everyone else will complain about losing the big picture amid all these tiny details.
Break stories down progressively, and just in time.
在每个故事讨论和拆分阶段,您都会牢记一个目的:
At each story discussion and splitting stage, you’ll do so with a purpose in mind:
你可以看到,如果你试图同时进行所有这四次对话,那将是一场漫长而令人筋疲力尽的对话。需要各种各样的人来权衡不同的方面。你可能已经从我的警告和你自己过去的经验中了解到,一大群人不能有效地一起工作——至少不是所有人都同时在同一个房间里。这就是为什么我们会随着时间的推移通过大量对话逐步分解故事。
You can see that if you tried to have all four of these conversations in the same sitting, it’d be a long, grueling conversation. It’d take a wide variety of people to weigh in on different aspects. And you’ve probably gathered from my warnings and your own past experience that big groups of people don’t work effectively together—at least not all in the same room at the same time. That’s why we break stories down progressively over time with lots of conversations.
在Asteroids游戏中,您必须非常小心地射击哪些小行星,因为一旦它们破碎,您就无法将分裂的小行星重新组合在一起。但是您可以将拆分的故事重新组合在一起。
In the Asteroids game, you have to be very careful about which asteroids you shoot because you can’t put split asteroids back together once they’re broken. But you can put split stories back together.
为避免积压大量小故事,将一堆故事放在一起,然后将它们的所有标题作为项目符号列表写在一张卡片上。在你的新卡片上用一个标题总结这些标题。瞧,你有一个大故事。
To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those titles with a single title on your new card. Voilà, you’ve got one big story.
当你想到它时,这是非常棒的东西。卡片和写在上面的标题是许多无形想法的有形手柄。想法比石头或厚重的文件更具可塑性。我们有时会忘记软件开发的另一个名字是知识工作。当我们忘记这一点,转而专注于文件和流程时,它就会变成枯燥而繁琐的事情。当我与管理大量积压的、充满小故事的人一起工作时,感觉就像秘书一样可怕。
This is pretty fantastic stuff when you think about it. The card, and the title written on it, is a tangible handle to lots of intangible ideas. Ideas are a lot more malleable than rocks or heavy documents. We sometimes forget that another name for software development is knowledge work. When we forget that and instead fixate on documents and process, it turns into something dry and secretarial. And when I work with people managing huge backlogs filled with tiny stories, it feels horribly secretarial.
我经常听到有人试图弄清楚这个故事地图的东西,说它“太多了”。当我问他们“出了什么问题?” 他们会告诉我如何创建一个非常大的整个系统图来讨论一个简单的功能。他们是对的:这太多了。所以不要那样做。
I often hear from people trying to figure out this story mapping stuff that it’s just “too much.” When I ask them “What went wrong?” they’ll tell me about creating a very large map of their whole system in order to discuss a simple feature. They’re right: that’s too much. So don’t do that.
仅映射您需要讲述您的功能故事的内容。
Map only what you need to tell a story about your feature.
例如,我曾与一家公司合作,对其协作文档编辑软件中的评论功能进行了一些更改。该团队在高层次上绘制了文档编辑,他们只使用了几张卡片。当他们到达评论区域时,他们添加了更多卡片,在一张卡片上使用大量项目符号来总结他们的产品今天所做的事情。然后他们开始讨论他们想要做出的改变,为他们正在考虑的所有细节和选项添加更多卡片。
For example, I was working with a company making some changes to the commenting feature in its collaborative document editing software. The team mapped document editing at a high level, and they only used a few cards for that. When they got to the area for commenting, they added more cards that summarized what their product did today using lots of bullets on a single card. Then they began to discuss changes they’d like to make, adding lots more cards for all the details and options they were considering.
将功能添加到现有产品时,请将功能映射到用户故事中该功能开始的位置之前,并稍微超出它的结束位置。不要映射你的整个产品。
When adding a feature into an existing product, map a little ahead of where the feature begins in your users’ story, and a little beyond where it ends. Don’t map your whole product.
请记住,故事地图支持关于用户和产品创意的对话。一个好的经验法则是:如果不需要讨论它,则不需要映射它。
Remember that story maps support conversations about your users and your product ideas. A good rule of thumb is this: if you don’t need to discuss it, you don’t need to map it.
我已经描述了整个破岩之旅,甚至告诫你在旧的 Atari 游戏中像对待小行星一样对待这些岩石,这样你就不会太快地打破它们。隐藏在所有这些策略中的是一个假设,即我们想出的很多故事都是大故事。但是,实际上,他们中的很多人都不是。在向用户交付产品或功能后,您会立即发现许多非常明显的小事情——您希望在交付之前就想到的事情,但您没有。至少我就是这样。对于那些事情,我没有机会讨论,也没有召集一个小组来进行产品发现,因为每个人都应该做这些事情。对于那些事情,我会将它们放入当前版本待办事项列表中,然后尽早与团队成员一起讨论它们,以便我们可以构建它们。错误和许多小改进也是如此。
I’ve described this whole rock-breaking journey, and even cautioned you to treat those rocks like asteroids in the old Atari game so you’re not tempted to break them down too fast. Hidden within all these strategies is the assumption that a lot of the stories we come up with are big. But, actually, a lot of them aren’t. After you deliver a product or feature to users, you’ll immediately find lots of little things that are dead obvious—things you wished you’d have thought of before shipping, but you didn’t. At least that’s what happens to me. For those things I don’t have an opportunity discussion, or pull together a group to do product discovery, because it’d be obvious to everyone they should be done. For those things, I’ll get them into a current release backlog and then as early as possible workshop them with team members so we can get them built. The same goes for bugs, and lots of little improvements.
如果您有传统的开发帽子,您可能会认为在构建软件时您已经完成了。但是敏捷开发和故事是为学习而构建的。在我们构建任何东西之前,我们花了很多时间来确保我们应该构建它,并就构建的内容达成一致。而且,在我们构建之后,我们会再次查看并询问是否应该构建它,以及它是否足够好。
If you’ve got a traditional development hat tightly on, you might believe you’re done when the software is built. But Agile development and stories are built for learning. We spend a lot of time before we build anything making sure we should build it, and agreeing together on what to build. And, after we build, we’ll look again and ask if should have built it, and if it’s good enough.
Let’s talk about all the opportunities you have to learn after you build.
让我们回到庆祝的部分。在开发和测试周期结束时,庆祝活动是有序的。您已经将一些想法、大量讨论、草图和挥手变成了一些诚实至善的工作软件。使用传统的需求流程会花费更长的时间。而且您和您的团队可能会对结果感到更少的所有权。
Let’s rewind to the celebrating part. At the end of a cycle of development and testing, celebration is in order. You’ve turned some ideas, lots of discussion, sketching, and hand waving into some honest-to-goodness working software. It would have taken a lot longer using a traditional requirements process. And you and your team would likely feel a lot less ownership of the result.
在击掌数次之后,是时候作为一个团队坐下来坦诚相见了看看我们取得的成就。如果我们对自己诚实,我们可能会发现一些我们可以改变的东西来改进软件。对于其中的每一件事,我们将编写另一个故事并将其添加到我们的发布待办事项列表中。我们将决定这些是我们需要立即做出的改变,还是我们可以推迟到残局时再做的改变。
After a few high-fives, it’s time to sit down as a team and take an honest look at what we’ve accomplished. If we’re being honest with ourselves, we’ll likely find some things we’d change to improve the software. For each of those things, we’ll write another story and add it to our release backlog. We’ll decide if these are changes we need to make right away, or changes we can defer ‘til later during our endgame.
在 Scrum 等流程中,这称为冲刺评审。如果您是 Scrum 从业者,您可能听说过欢迎所有人参加这次评审,但我建议您做一些不同的事情。
In processes like Scrum, this is called a sprint review. If you’re a Scrum practitioner, you may have heard that everyone is welcome at this review, but I’m going to suggest you do something different.
密切合作的团队进行了最后的、最好的故事对话、就构建内容达成一致并共同构建它需要时间和安全的地方来公开讨论他们的工作。团队以外的其他人,包括业务领导,对产品的看法很重要,团队需要听取他们的意见。但这些人并没有参与建立对构建内容细节的共同理解的对话。他们没有参与制定软件构建详细计划的讨论。他们并没有与团队一起工作,因为它将所有这些讨论和协议变成了工作软件。我们需要首先评估我们是否按照我们希望的质量水平和我们计划的时间框架构建了我们设想的内容。在团队产品审查和反思中执行此操作.
The team that worked closely together, had those last, best story conversations, agreed on what to build, and worked together to build it needs time and a safe place to openly discuss their work. What others outside the team, including business leadership, think of the product is important and the team needs to hear their opinions. But those people weren’t in the conversations that built shared understanding about the details of what to build. They weren’t part of the discussions that created the detailed plans to build software. And they weren’t working alongside the team as it turned all these discussions and agreements into working software. We need to first evaluate if we’ve built what we envisioned at the quality level we hoped for and in the timeframe we planned. Do this in a team product review and reflection.
当团队对他们的产品进行了公正的评估后,扩大受众范围以包括组织中感兴趣的任何其他人。该小组需要了解你们作为一个团队进行的讨论以及你们所做的任何权衡。请记住,您已经翻译成可运行软件的故事很可能是从成品的更大愿景中切下的小石头。团队外的人可能希望看到成品。他们可能会指出缺少的内容,因为他们不是您决定推迟到以后的计划会议的一部分。期待那个。并帮助他们了解您刚刚构建的部分如何融入更大的计划。在利益相关者产品审查中执行此操作。
When the team has given their product a fair evaluation, widen the audience to include anyone else in the organization that’s interested. This group will need some insight on the discussions you had as a team and any tradeoffs you made. Remember, the stories you’ve translated to working software are likely little rocks chipped off of a larger vision of the finished product. People outside the team may be expecting to see that finished product. They’re likely to point out what’s missing because they weren’t part of the planning sessions where you decided what to defer until later. Expect that. And help them understand how the pieces you’ve just built fit into the bigger plan. Do this in a stakeholder product review.
我很自信,当我使用我喜欢的产品时,我不会欣赏其中的所有小细节和决定。事实上,如果它工作得很好,我几乎不会注意到这个产品。我没有注意到我的移动设备是如何断开和重新建立互联网连接的。我没有注意到当我在我的任务管理软件的移动应用程序中更改某些内容的位置时,Web 版本似乎立即同步了。但这些都是重要的品质。如果他们不在,我会注意到的。你们作为一个团队一直在考虑很多细节。但是,奇怪的是,您可能不希望用户和其他人注意到它们。事实上,你可能想注意到他们没有注意到他们。
I’m confident when I use a product I like that I’m not appreciating all the little details and decisions that went into it. In fact, if it’s working really well, I hardly notice the product at all. I don’t notice how my mobile device loses and reestablishes an Internet connection. I don’t notice how when I change the position of something in the mobile app of my task management software that the web version seems to be immediately in sync. But these are important qualities. And I’d notice if they weren’t there. You as a team have been stewing in lots of details. But, oddly, you may not want users and others to notice them. In fact, you may want to notice that they don’t notice them.
当您将足够多的软件放在他们面前时,您将从组织中的利益相关者、购买您产品的客户以及将使用它的个人用户那里学到最多,他们可以清楚地看到它如何帮助他们达到以下目标之一他们的目标。
You’ll learn the most from the stakeholders in your organization, customers who buy your product, and individual users who’ll use it when you put enough software in front of them that they can clearly see how it’ll help them reach one of their goals.
如果你的破岩过程做得很好,你最终会得到很多小的、可拼砌的零件。这些部分中的每一个都让您和您的团队学到了一些东西。但是,如果你做得对,那些小部分可能不足以与其他群体相关。
If you did your rock-breaking process well, you ended up with lots of small, buildable parts. Each of those parts allowed you and your team to learn something. But, if you were doing it right, those small parts are likely not enough to be relevant to other groups.
在我看来,我把这想象成我们构建的小块软件像乐高积木一样堆积起来。我把所有这些积木都装到一个老式秤上,那种有两个平台,一侧有配重的秤。我衡量这堆越来越多的软件的是一块更大的乐高积木,它代表足够——足以让用户完成一项任务或达到一个目标;足以让客户将其视为其价值主张的一部分;足以让业务利益相关者了解它如何帮助我们的组织实现业务目标。当足够多的软件堆积起来并达到顶峰时,就该与用户一起测试该软件,与客户一起审查它,或者与业务利益相关者一起审查它。
In my mind, I picture this as small bits of software we build piling up like LEGO bricks. I load all those bricks onto an old-fashioned scale, the kind with two platforms and a counterweight on one side. What I weigh this growing pile of software against is a bigger LEGO brick that represents enough—enough to allow a user to complete a task or reach a goal; enough for customers to see it as part of their value proposition; enough for business stakeholders to see how it helps our organization reach a business goal. When enough software piles up and tips the scales, it’s time to test that software with users, review it with customers, or review it with business stakeholders.
作为一个由密切合作者组成的团队,您需要审查每个故事的结果,不仅要学习和改进您的产品,还要学习和改进您的计划方式和合作方式。当从其他群体获得反馈和学习时,要注意哪些对这些群体来说已经足够了。
You as a team of close collaborators need to review the results of every single story to learn and improve not only your product, but also the way you plan and the way you work together. When getting feedback and learning from other groups, be sensitive to what is enough for those groups.
当我们开始时,我们可能非常自信我们正在构建正确的东西,但要保持自信,与用户一起测试工作软件很重要。
We may have been pretty confident that we were building the right things when we started, but to stay confident it’s important to test the working software with users.
请注意,我在这里说的是测试。我们不会通过玩“展示和讲述”的游戏从用户那里学到很多东西——也就是说,通过向他们展示它并让他们想象使用它并决定他们是否喜欢它。这有点像在陈列室地板上看一辆新车,并试图决定你是否喜欢驾驶它。测试您的软件将帮助用户真正评估它是否解决了他们遇到的问题。作为一个团队,我们将通过观察他们使用它来了解更多。如果您和您的团队进行了良好的故事对话,您可能会谈论用户、为什么他们会重视您正在构建的东西,以及他们会如何使用它。正是看着他们使用它,才真正验证了这些假设。
Notice that I said test here. We don’t learn much from users by playing “show and tell”—that is, by demonstrating it to them and asking them to imagine using it and decide if they’d like it. It’s a little like looking at a new car on a showroom floor and trying to decide if you’d enjoy driving it. Test-driving your software will help users really evaluate if it’s solving a problem they have. As a team, we’ll learn more by watching them use it. If you and your team were having good story conversations, you likely talked about users, why they’d value what you were building, and how they’d use it. It’s watching them use it that really validates those hypotheses.
当您拥有足够多的软件来允许用户完成对他们有意义的事情时,就该进行测试了。您可能不是在测试全新的东西。您可能对产品已有的功能进行了更改或增强。花时间与用户一起观察他们使用你的软件做真实的工作。
When you’ve got enough software to allow users to accomplish something meaningful to them, it’s time to test. You may not be testing something completely new. You may have made changes or enhancements to something your product already does. Spend time with users to observe them using your software doing realistic work.
您构建了少量软件并作为一个团队审查了它的每一部分。您定期与组织内部的利益相关者、将购买或采用您的产品的客户以及将使用它的用户一起审查它。但是,如果您还记得本书的开头,它并不是我们真正想要的软件——它是我们在软件交付并投入使用后得到的结果。
You’ve built small amounts of software and reviewed every bit of it as a team. You’ve periodically reviewed it with stakeholders insider your organization, and with customers who’ll buy or adopt your product, and with users who’ll use it. But, if you remember where this book started, it’s not the software we really wanted—it’s the outcomes we get after the software is delivered and put into use.
当您觉得自己已经构建了足够多的内容并有信心获得这些结果时,就该将软件发布到世界上了。
When you feel like you’ve built enough that you’re confident you’ll get those outcomes, then it’s time to release the software into the world.
我又想象了一个秤,上面堆满了我与用户一起测试过的软件块,反复改进,现在我有信心可以发布了。我将平衡那堆越来越大的砖块和另一块更大的砖块,这块砖块也代表足够——足以发布并在目标受众中取得成功。当我受够了,是时候释放了。
I picture one more scale that’s piling up with bricks of software that I’ve tested with users, iteratively improved, and I’m now confident could be released. I’ll balance that growing pile against yet another, larger brick that also represents enough—enough to release and be successful with its target audience. When I’ve got enough, it’s time to release.
您需要计划从每个版本中学习。请不要发布软件并坐等您的客户和用户抱怨。这些抱怨是结果。但他们往往滞后于他们的真实感受以及您的产品实际性能的指标。对于每个版本,作为一个团队讨论你将如何衡量或观察你的产品的用户,看看你是否真的得到了你预期的结果。讨论并决定你将如何:
You’ll need to plan to learn from each release. Please don’t release software and sit around waiting for your customers and users to complain. Those complaints are outcomes. But they’re often lagging indicators of how they really feel and how well your product will really do. For each release, discuss as a team how you’ll measure or observe the users of your product to see if you really got the outcomes you expected. Discuss and decide how you’ll:
作为一个团队,定期讨论你们学到了什么,然后采纳你们的想法进行改进并撰写更多故事。有些您会认为非常重要,可以立即实施。以及其他你会看到的机会,可以添加到你的机会积压中。
As a team, routinely discuss what you’ve learned, and then take your ideas for improvement and write more stories. Some you’ll see as important enough to implement right away. And others you’ll see as opportunities to add to your opportunity backlog.
有一些公司和一些软件允许我们在有足够的时候发布。但是对于大量的公司和产品,如果不是大多数,我们需要按计划发布。如果我们一直在有效地使用我们的开发策略,我们就已经在我们早期的开场故事中奠定了基础,使用中期故事构建了产品,并且在发布时,我们正在播放我们的终局故事。
There are some companies and some software that allow us to release whenever we have enough. But for a great number of companies and products, if not most of them, we need to release on a schedule. If we’ve been using our development strategy effectively, we’ve laid down a foundation in our early opening-game stories, built up the product using midgame stories, and when it comes time to release, we’re playing our endgame stories.
现在我需要提醒你一些关于软件开发的更多真相。
Now I need to remind you of a few more truths about software development.
软件永远不会真正完成。
Software is never really done.
您将在较短的开发周期内为您的团队完成的每个故事完成软件实施。但是您可能不会完成您在开发开始时想象的每个故事,或者在您学习每个周期时进行识别。但是,如果您使用了有效的开发策略,则该软件在发布时会尽可能好。
You’ll finish implementing the software for each story your team takes on during a short development cycle. But you likely won’t finish every story you imagine at the outset of development, or identify as you learn each cycle. If you’ve used an effective development strategy, however, the software will be as good as it possibly can be at the time it’s released.
结果永远没有保险。
Outcomes are never insured.
尽管你已经做了所有的工作来验证你正在构建正确的东西,但使用你的产品的人通常不会像预期的那样行事。计划学习每个版本。计划根据您所学的内容进行更改。
In spite of all the work you’ve done to validate that you’re building the right things, people using your product often don’t behave as predicted. Plan to learn with each release. Plan to make changes based on what you’ve learned.
发布后所做的改进是最有价值的。
Improvements made after release are the most valuable.
当用户开始频繁采用和使用您的软件时,您会观察到那些不可预知的事情,从而产生最深刻的洞察力。如果您计划时间来真正衡量和观察结果,您将得到真正热爱您的产品和对您的组织真正有价值的产品的人的回报。
It’s those unpredictable things that you’ll observe when users begin to adopt and use your software frequently that yield the most insight. If you plan for time to really measure and observe outcomes, you’ll be rewarded with people who really love your product and a product that’s really valuable for your organization.
您将逐个故事地完成您的产品发布故事。当您接近您承诺的交付日期时——承诺的交付日期总是存在的——对于每个主要用户活动都会问,“如果我们必须立即发货,我们会给自己打几分?” 如果你像我的孩子在学校那样使用字母等级,你最终会得到你的产品的成绩单。
You’ll complete your product release story by story. As you draw near the date you promised to deliver—and there’s always a promised delivery date—for each major user activity ask, “If we had to ship right now, what grade would we give ourselves?” If you use letter grades like my kids get in school, you’ll end up with a report card for your product.
例如,如果您在承诺的发布日期前几周查看了具有五项主要活动的产品或功能,并看到了A、A–、B+、D、B+的成绩单,您可能希望将剩余的几周和关注用户工作流程中当前评分为D的部分。如果最后你用A s 和B s 发布,那很好。当然,全A会更好,但按时完成可能更重要。
For example, if you looked at a product or feature with five major activities a few weeks before its promised release date, and saw a report card of A, A–, B+, D, B+, you might want to take the remaining weeks and focus on the part in the user’s workflow that’s currently graded a D. If in the end you release with A s and B s, that’s pretty good. Of course, straight A s would be better, but getting it out on time may be more important.
当您临近产品发布日期时,一起评估发布准备情况。我向你保证,每个人都想知道。
As you draw near the release date of your product, work together to assess release readiness. I promise you, everyone wants to know.
这本书快完成了。如果您已经读到这里,您可能对其发布准备情况有一些看法。你可以回到目录并在每一章上写下你的字母等级。拍一张智能手机照片并发送给我。我很想看看。
This book is almost done. If you’ve read this far, you may have some opinions about its release readiness. You could go back to the table of contents and write your letter grade on each chapter. Take a smartphone photo and send it to me. I’d love to see it.
[ 16 ]这种过程改进讨论通常称为回顾,并且有很多很好的方法来执行回顾。如果您想查看更全面的回顾方法秘诀,请尝试Esther Derby 和 Diana Larsen(Pragmatic)合着的《敏捷回顾》一书。
[16] This process improvement discussion is commonly called a retrospective, and there are lots of great approaches to performing one. If you’d like to look at a more comprehensive recipe of retrospective approaches, try the book Agile Retrospectives by Esther Derby and Diana Larsen (Pragmatic).
就像一个好的软件产品一样,这本书还没有真正完成。整本书中有很多我遇到的人提供的很好的例子,他们告诉我他们在故事和故事地图方面所做的很酷的事情。我的硬盘上还有很多故事,我没有时间将它们提炼并收录到书中,这让我很难过。
Just like a good software product, this book isn’t really done. Throughout the book are lots of great examples contributed by people I’ve met who tell me about the cool things they’re doing with stories and story mapping. I’ve got a lot more stories on my hard drive, too, and it’s killing me that I don’t have time to get them refined and included in the book.
关于故事和故事地图,我还可以讨论更多细节。而且我敢肯定,关于在您自己的上下文中使用故事,您还有一些悬而未决的问题。当我接近本书的结尾时,我也担心这一点。
There are also a lot more details I could discuss about stories and story maps. And I’m sure you’ve got unanswered questions about using stories in your own context. As I reach the close of this book, I worry about that, too.
作为一名开发人员、UI 设计师和产品经理,我可以告诉你,我很少对产品发布感到高兴。那是因为那时我才知道所有我无法包括的东西,以及所有可以通过更多时间润色而变得更好的小东西。如果你真的关心你正在构建的东西,我希望你也会有这种感觉。
As someone who’s been a developer, a UI designer, and a product manager, I can tell you I’ve rarely been happy at product release. And that’s because it’s then that I know about all the things I couldn’t include, and about all the little things that could be better with just a bit more time to polish. If you really care about what you’re building, I expect you’ll feel that way as well.
我将重复我之前在第 4 章中使用的达芬奇语录:
I’ll repeat the da Vinci quote I used earlier in Chapter 4:
伟大的艺术永远不会完成,只会被抛弃。
Great art is never finished, only abandoned.
我不会说这本书是伟大的艺术。但我会说,当有更多的事情可以做时,我已经放弃了它。我会把更多的事情留给你,当你发现自己更好的合作方式来创造伟大的产品时,希望能收到你的来信。
I’ll stop short of saying this book is great art. But I will say I’ve abandoned it when there’s more that could be done. I’ll leave that more to you, and expect to hear from you when you’ve discovered your own better ways for working together to create great products.
这是本书中最难写的部分之一。在我的整个职业生涯中,我很幸运能够得到很多人的支持。我已经并将继续从我遇到和共事的每个人那里得到如此多的鼓励。所以,让我害怕的是,一旦我开始感谢别人,我就会把某人排除在外。如果我把你排除在外,我很抱歉,而且我怀疑你的公司很好。
This was one of the hardest parts of this book to write. I’ve been blessed enough to enjoy the support of a huge number of people throughout my career. I have and continue to receive so much encouragement from everyone I meet and work with. So, what scares me is that as soon as I start thanking people, I’m going to leave someone out. If I’ve left you out, I am very sorry, and I suspect you’re in good company.
而且,另一件事是我很确定我没有任何原创想法。我听说有人争辩说没有原创的想法了。但具体对我而言,我所知道的一切都是从过去二十年与我共事的智者那里学到的。从这些有见地的朋友和同龄人那里,我学习并应用了新的想法和实践。通过与他们长时间的讨论,我学会了解释和深刻理解我在练习手艺时的经历。似乎很难将本书中的任何想法归功于本书,因为我知道大多数想法都是从别人那里借来的,或者只是从别人那里偷来的。
And, another thing is that I’m pretty sure I don’t have any original ideas. I’ve heard it argued that there are no original ideas left. But for me specifically, everything I know I’ve learned from the wise people I’ve worked with over the past two decades. From these insightful friends and peers I’ve learned and applied new ideas and practices. Through long discussions with them, I’ve learned to interpret and deeply understand the experiences I’ve had when practicing my craft. It seems hard to take credit for any of the ideas in this book since I know most were borrowed or simply stolen from others.
每当我确实有了我认为是原创的想法时,我就会想起隐忘症。这是一个有趣的词,适用于乔治·哈里森 (George Harrison) 和翁贝托·埃科 (Umberto Eco) 等知名人士所犯的意外剽窃。当被遗忘的记忆重新出现而没有被识别为记忆时,就会出现隐忘症。crytomnesiac 相信他们刚刚想出的好主意是新的和原创的,而不是对他们读过、听过或以其他方式经历过的事情的遗忘记忆。我在下面感谢的人很可能是我无意中窃取的许多人。
Whenever I do have what I believe to be an original idea, I’m reminded of cryptomnesia. It’s a fun word that applies to the accidental plagiarism that reputable people like George Harrison and Umberto Eco are guilty of. Cryptomnesia occurs when a forgotten memory returns without it being recognized as a memory. The crytomnesiac believes the great idea they’ve just come up with is new and original, and not the forgotten memory of something they’ve read, heard, or otherwise experienced. The people I’m thanking below are quite likely many of the people I’ve unintentionally stolen from.
因此,在序言中,我将开始:
So with that preamble, I’ll get started:
我几乎放弃了写书。在过去的十年里,当我试图写作时,我遇到了一个真正的问题。我似乎可以写短文或发表演讲,但一旦我尝试写超过几千字的东西时,事情就跑偏了。我可以最好地将我的书写作描述为动物标本剥制术。那就是我会拿走一些活生生的美丽东西,然后杀死它并填满它。我所能希望的最好的就是它会栩栩如生。Peter Economy 让我摆脱了那个循环。正是他多年的写作经验和他始终积极和支持的态度帮助我找到了一个行之有效的书面声音。我很感谢彼得。如果你正在努力写一本书,你应该打电话给彼得。
I’d practically given up on writing a book. I’ve had a real problem when I was trying to write over the past ten years. I seemed to be able to write short articles, or give a talk, but as soon as I tried to write anything longer than a couple thousand words, things went sideways. I can best describe my book writing as taxidermy. That is I’d take something living and beautiful and then kill it and stuff it. The best I could hope for is that it would be lifelike. Peter Economy broke me out of that cycle. It was his years of experience writing and his always positive and supportive attitude that helped me find a written voice that worked. I’m grateful to Peter. If you’re struggling to get a book written, you should call Peter.
Martin Fowler、Alan Cooper 和 Marty Cagan 都是我心目中的英雄。我很高兴与他们所有人会面、一起工作并享受与他们所有人的长时间对话。他们的想法影响了我的整个职业生涯。三人中有两人认为在书中加入三个前言是个坏主意,但我很高兴我坚持了下来,他们也同意了。他们代表了工程、用户体验和产品思维的声音,我认为这些对于创造成功的产品至关重要。我认为至关重要的是,您,读者,能听到他们每个人的意见。
Martin Fowler, Alan Cooper, and Marty Cagan are all heroes of mine. I’ve had the pleasure of meeting with, working with, and enjoying long conversations with all of them. Their thinking has influenced mine throughout my career. Two of the three thought it was a bad idea to have three forewords in the book, but I’m glad I insisted, and they agreed. They represent the voices of engineering, user experience, and product thinking that I see as critical to creating successful products. I think it was critical that you, the reader, heard from each of them.
Alistair Cockburn 十多年来一直是我的朋友和导师。我很确定,我认为我的伟大想法中的大部分都是直接从 Alistair 以及我与他的长时间对话中窃取的。把我贴在墙上和桌面上的故事卡片模型称为“故事地图”,来自其中一次对话。当我试图向 Alistair 解释它是什么时,我记得我说过“这只是一张故事地图”。“那么,你为什么不那样称呼它呢?”阿利斯泰尔说。那而不是我一直在折腾的其他愚蠢的名字。
Alistair Cockburn has been a friend and mentor of mine for over a decade. I’m quite certain that much of what I believe are my great ideas were stolen directly from Alistair and my long conversations with him. Calling the model of story cards I put on walls and tabletops a “story map” came from one of these conversations. As I was trying to explain to Alistair what it was I recall saying “it’s just a map of stories.” “Then, why don’t you call it that” Alistair said. That instead of the other silly names I’d been tossing around.
多年前我开始用卡片讲故事和建立产品待办事项列表的做法来自于我从朋友拉里·康斯坦丁那里学到的混蛋做法。如果没有直接向 Larry 学习的机会,故事映射的实践以及我对用户体验的看法将永远不会出现。
What I started doing with cards years ago to tell stories and build product backlogs came from bastardizing practices I learned from my friend Larry Constantine. The practice of story mapping and how I think of user experience would never have come about without the opportunity to learn directly from Larry.
大卫·哈斯曼 (David Hussman) 多年来一直是我明智的朋友、支持者和志趣相投的人。看着大卫讲故事并得到他的鼓励,这帮助我找到了今天的声音。在他们被称为故事地图之前,大卫正在创建故事地图。
David Hussman has been my wise friend, supporter, and a kindred spirit to me for years now. It’s watching David tell stories and receiving his encouragement that’s helped me find the voice I have today. David was creating story maps before they were called that.
而且,如果没有 Tom 和 Mary Poppendieck 的支持,我永远不可能完成一本书。尤其是汤姆,他读了我过去十年来最糟糕的一些动物标本剥制术,并且仍然提供了鼓励的话。几个月前,他拒绝离开我的房子,直到我把我的终稿寄给 O'Reilly。如果他没有,我会一直摆弄这本书,永远不会认为它足够好。
And, I’d never have gotten a book completed without the support of Tom and Mary Poppendieck. Tom in particular has read some of my worst taxidermy over the past decade, and still offered words of encouragement. A few months ago, he refused to leave my house until I sent my final draft to O’Reilly. If he hadn’t, I’d have kept twiddling with the book, never considering it good enough.
一路上作为支持者和良好建议来源脱颖而出的其他朋友包括 Zhon 和 Kay Johansen、Aaron Sanders 和 Erica Young、Jonathan House、Nate Jones 和 Christine DelPrete。
Other friends that stand out as supporters and sources of good advice along the way include Zhon and Kay Johansen, Aaron Sanders and Erica Young, Jonathan House, Nate Jones, and Christine DelPrete.
特别感谢 Gary Levitt、Globo.com 的所有人员、Liquidnet 的 Eric Wright 以及我在 Workiva 的所有朋友,感谢他们让我在本书的第一章讲述他们的故事。
Special thanks to Gary Levitt, all the people at Globo.com, Eric Wright from Liquidnet, and all my friends at Workiva for letting me tell their stories in the first chapters of this book.
多年来,我无数次被想告诉我他们如何使用故事地图或应用我给他们的建议的故事的人拦住。我内疚的秘密是,我从他们身上学到的比我认为他们从我身上学到的要多。我很高兴能从其中一小部分人那里为本书做出贡献。特别感谢那些可以在短时间内为我做出贡献的人:Josh Seiden、Chris Shinkle、Sherif Mansour、Ben Crothers、Michael Vath、Martina Luenzman、Andrea Schmieden、Ceedee Doyle、Erin Beierwaltes、Aaron White、Mat Cropper、Chris Gansen和杰森·库内什、里克·库西克、尼古拉·亚当斯和史蒂夫·巴雷特。
Countless times over the years I’ve been stopped by people who wanted to tell me their stories about how they’d used story mapping or applied a piece of advice I’d given them. My guilty secret is that I learn more from them than I think they get from me. I was happy to get contributions from just a fraction of them for this book. Special thanks to those that could get me a contribution given very short notice: Josh Seiden, Chris Shinkle, Sherif Mansour, Ben Crothers, Michael Vath, Martina Luenzman, Andrea Schmieden, Ceedee Doyle, Erin Beierwaltes, Aaron White, Mat Cropper, Chris Gansen and Jason Kunesh, Rick Cusick, Nicola Adams, and Steve Barrett.
我与一大群人交谈并从中了解到我根本没有给足够的时间来满足我不合理的最后期限。这些人包括:Ahmad Fahmy、Tobias Hildenbrand、Courtney Hemphill、Samuel Bowles、Rowan Bunning、Scout Addis、Holly Bielawa 和 Jabe Bloom。对于这些人和所有阅读本文的人,我仍然想要你的故事。也许我会发布这本书的特别导演剪辑版,其中包括所有这些已删除的场景。
There’s a big group of people that I spoke with and learned from that I simply didn’t give enough time to meet my unreasonable deadline. These people include: Ahmad Fahmy, Tobias Hildenbrand, Courtney Hemphill, Samuel Bowles, Rowan Bunning, Scout Addis, Holly Bielawa, and Jabe Bloom. To these people and all of you reading this, I still want your stories. Perhaps I’ll release a special directors cut of the book that includes all these deleted scenes.
在完成本书的最后阶段,我收到了来自 Barry O'Reilly、Todd Webb 以及在最后一刻来自 Petra Wille 的宝贵详细评论。他们所有详细的评论帮助我消除了书中的粗糙边缘。
In the final stretch of getting this book done, I received valuable detailed reviews from Barry O’Reilly, Todd Webb, and at the last minute from Petra Wille. All of their detailed comments helped me smooth out the rough edges in the book.
最后,感谢 Mary Treseler 和 O'Reilly 的制作团队容忍我的延误和奇怪的日程安排,并陪我到最后。
Finally, thanks to Mary Treseler and the production team at O’Reilly for putting up with my delays and funky schedule, and sticking with me to the bitter end.
Adlin、Tamara 和 John Pruitt。角色基本生命周期:角色构建和使用指南。伯灵顿:摩根考夫曼,2010 年。
Adlin, Tamara, and John Pruitt. The Essential Persona Lifecycle: Your Guide to Building and Using Personas. Burlington: Morgan Kaufmann, 2010.
阿季奇,戈伊科。影响图:对软件产品和项目产生重大影响。英国萨里:发人深省,2012 年。
Adzic, Gojko. Impact Mapping: Making a Big Impact with Software Products and Projects. Surrey, UK: Provoking Thoughts, 2012.
--. 实例说明:成功的团队如何交付正确的软件。庇护岛:曼宁出版社,2011 年。
--. Specification by Example: How Successful Teams Deliver the Right Software. Shelter Island: Manning Publications, 2011.
阿米蒂奇,约翰。“敏捷方法是否适合设计”,Interactions,第 11 卷,第 1 期,2004 年 1 月至 2 月。http://dl.acm.org/citation.cfm?id= 962352。
Armitage, John. “Are Agile Methods Good for Design,” Interactions, Volume 11, Issue 1, January-February, 2004. http://dl.acm.org/citation.cfm?id=962352.
贝克,肯特。 极限编程解释:拥抱变化。纽约:Addison-Wesley Professional,1999 年。
Beck, Kent. Extreme Programming Explained: Embrace Change. New York: Addison-Wesley Professional, 1999.
贝克、肯特和迈克尔·福勒。规划极限编程。纽约:Addison-Wesley Professional,2000 年。
Beck, Kent, and Michael Fowler. Planning Extreme Programming. New York: Addison-Wesley Professional, 2000.
卡根,马蒂。启发:如何创造客户喜爱的产品。桑尼维尔:SVPG 出版社,2008 年。
Cagan, Marty. Inspired: How to Create Products Customers Love. Sunnyvale: SVPG Press, 2008.
程,凯文。明白我的意思:如何使用漫画来交流思想。布鲁克林:罗森菲尔德媒体有限责任公司,2012 年。
Cheng, Kevin. See What I Mean: How to Use Comics to Communicate Ideas. Brooklyn: Rosenfeld Media, LLC, 2012.
科伯恩,阿利斯泰尔。敏捷软件开发。纽约:Addison-Wesley Professional,2001 年。
Cockburn, Alistair. Agile Software Development. New York: Addison-Wesley Professional, 2001.
--. 编写有效的用例。纽约:Addison-Wesley Professional,2000 年。
--. Writing Effective Use Cases. New York: Addison-Wesley Professional, 2000.
科恩,迈克。应用的用户故事:用于敏捷软件开发。纽约:Addison-Wesley Professional,2004 年。
Cohn, Mike. User Stories Applied: For Agile Software Development. New York: Addison-Wesley Professional, 2004.
Constantine、Larry L. 和 Lucy AD Lockwood。使用软件:以使用为中心的设计模型和方法实用指南。纽约:Addison-Wesley Professional,1999 年。
Constantine, Larry L., and Lucy A.D. Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. New York: Addison-Wesley Professional, 1999.
库珀,艾伦。囚犯正在经营庇护所:为什么高科技产品让我们发疯以及如何恢复理智。印第安纳波利斯:Sams – Pearson Education,2004 年。
Cooper, Alan. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis: Sams – Pearson Education, 2004.
戈瑟夫,杰夫。精益用户体验:应用精益原则改善用户体验。塞瓦斯托波尔:O'Reilly Media,2013 年。
Gothelf, Jeff. Lean UX: Applying Lean Principles to Improve User Experience. Sebastopol: O’Reilly Media, 2013.
Jeffries、Ron、Ann Anderson 和 Chet Hendrickson。安装了极限编程。纽约:Addison-Wesley Professional,2007 年。
Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. New York: Addison-Wesley Professional, 2007.
克莱因,劳拉。精益创业的用户体验:更快、更智能的用户体验研究和设计。塞瓦斯托波尔:O'Reilly Media,2013 年。
Klein, Laura. UX for Lean Startups: Faster, Smarter User Experience Research and Design. Sebastopol: O’Reilly Media, 2013.
里斯,埃里克。精益创业:当今的企业家如何利用持续创新来创造极其成功的企业。纽约:Crown Business,2011 年。
Ries, Eric. The Lean Startup: How Today’s Entepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011.
是的,德西瑞。“适应以用户为中心的敏捷设计的可用性调查,”可用性研究杂志,卷。2,第 3 期,2007 年 5 月。http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html。
Sy, Desiree. “Adapting Usability Investigations for Agile User-Centered Design,” Journal of Usability Studies, Vol. 2, Issue 3, May 2007. http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html.
汤姆德马科等人。肾上腺素瘾君子和模板僵尸:了解项目行为模式。纽约:多塞特宫,2008 年。
Tom Demarco et al. Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. New York: Dorset House, 2008.
耶茨,仁。蛋糕残骸:当专业蛋糕搞笑地出错时。堪萨斯城:Andrews McMeel 出版社,2009 年。
Yates, Jen. Cake Wrecks: When Professional Cakes Go Hilariously Wrong. Kansas City: Andrews McMeel Publishing, 2009.
User Story Mapping封面上的动物是一种淡紫色胸卷毛,通常被认为是世界上最美丽的鸟类之一,拥有柔和的羽毛、醒目的田野标记和长长的尾巴飘带。它是肯尼亚和博茨瓦纳的国鸟,在南部非洲的大部分地区相对常见和广泛分布。
The animal on the cover of User Story Mapping is a lilac-breasted roller, often considered one of the most beautiful birds in the world with its pastel plumage, striking field marks, and long tail streamers. It’s the national bird of both Kenya and Botswana, and is relatively common and widespread throughout much of southern Africa.
这些鸟通常是孤独的或成对出现,但在冬季可能会留在小家庭中。它们栖息在树木和杆子顶端的制高点,并在观察猎物接近时保持静止。在落到受害者身上后,它们可能会将猎物击打在岩石上或地面上以将其杀死,然后再将其整个吞下。
These birds are typically solitary or are found in pairs, but may stay in small family groups during the winter months. They perch on high vantage points at the very tops of trees and poles, and stay still while watching for prey to approach. After dropping onto a victim, they may beat their prey against a rock or on the ground to kill it before swallowing it whole.
这些鸟是一夫一妻制(据信终生交配),“roller”这个名字实际上来自鸟类在交配季节使用的空中展示。丁香胸滚筒会从相当高的高度俯冲,然后在空中翻滚,同时发出响亮的叫声以吸引伙伴。
The birds are monogamous (believed to mate for life) and the name “roller” actually comes from the aerial displays the birds use during mating season. Lilac-breasted rollers will dive from a considerable elevation, and then roll in the air while simultaneously letting out a loud call to attract a partner.
O'Reilly 封面上的许多动物都濒临灭绝;所有这些对世界都很重要。要了解有关如何提供帮助的更多信息,请访问animals.oreilly.com。
Many of the animals on O’Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.
封面图片来自 Braukhaus Lexicon。封面字体是 URW Typewriter 和 Guardian Sans。文字字体为Adobe Minion Pro;标题字体为 Adobe Myriad Condensed;代码字体是 Dalton Maag 的 Ubuntu Mono。
The cover image is from Braukhaus Lexicon. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag’s Ubuntu Mono.
| 修订记录 | |
| 2014-09-05 | 首次发布 |
版权所有 © 2014 杰夫巴顿
Copyright © 2014 Jeff Patton
购买 O'Reilly 书籍可用于教育、商业或促销用途。大多数书籍也有在线版本 ( http://safaribooksonline.com )。如需更多信息,请联系我们的企业/机构销售部:800-998-9938 或corporate@oreilly.com。
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
Nutshell Handbook、Nutshell Handbook 徽标和 O'Reilly 徽标是 O'Reilly Media, Inc. 的注册商标。User Story Mapping、丁香胸卷轴的图像和相关商业外观是 O'Reilly Media 的商标,公司
Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. User Story Mapping, the image of a lilac-breasted roller, and related trade dress are trademarks of O’Reilly Media, Inc.
制造商和销售商用来区分其产品的许多名称都被声明为商标。如果这些名称出现在本书中,并且 O'Reilly Media, Inc. 知道商标声明,则这些名称已印在大写字母或首字母大写字母中。
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps.
1005 Gravenstein 公路北
1005 Gravenstein Highway North
塞瓦斯托波尔,CA 95472
Sebastopol, CA 95472